Как создать сертификаты SSL (TLS) –

Что делать, "ненадежный сертификат" на iphone ios 13 – не удается проверить приложение

С помощью команды smime

Решение для безопасного и высокозащищенного кодирования любого файла в OpenSSL и командной строке:

Для шифрования файлов вы должны иметь готовый сертификат X.509 в формате PEM.

Сгененировать незашифрованный приватный ключ вместе с сертификатом можно следующей командой:

openssl req -x509 -nodes -days 100000 -newkey rsa:8192 -keyout private_key.pem -out certificate.pem

Сгененировать зашифрованный приватный ключ вместе с сертификатом можно следующей командой:

openssl req -x509 -days 100000 -newkey rsa:8192 -keyout private_key.pem -out certificate.pem

С уже существующим зашифрованным или незашифрованным приватным ключом сертификат можно создать следующей командой:

openssl req -x509 -new -days 100000 -key private_key.pem -out certificate.pem

Чтобы зашифровать файл выполните:

openssl smime -encrypt -binary -aes-256-cbc -in plainfile.zip -out encrypted.zip.enc -outform DER yourSslCertificate.pem

В этой команде:

• smime — ssl команда для S/MIME утилиты
• -encrypt — выбранным действием с файлом является шифрование
• -binary — использовать безопасный файловый процесс. Обычно входное сообщение преобразуется в «канонический» формат, как того требует спецификация S/MIME, этот переключатель отключает его. Это необходимо для всех двоичных файлов (например, изображений, звуков, ZIP-архивов).
• -aes-256-cbc — выбран шифр AES в 256 бит для шифрования (сильный). Если не указано, используется 40-битный RC2 (очень слабый).
• -in plainfile.zip — файл для шифрованиия
• -out encrypted.zip.enc — файл для сохранения зашифрованных данных
• -outform DER — закодировать выходной файл как двоичный файл. Если не указан, файл будет закодирован в base64, а размер файла будет увеличен на 30%.
• yourSslCertificate.pem — имя файла вашего сертификата. Он должен быть в формате PEM.

Эта команда может очень эффективно сильно шифровать большие файлы независимо от их формата.

Известная проблема: что-то не так происходит, при попытках зашифровать огромный файл (> 600 МБ). Ошибка не выводится, но зашифрованный файл будет повреждён. Всегда проверяйте каждый файл! (или используйте PGP — больше поддержки шифрования файлов с открытым ключом).

Расшифровка файла:

openssl smime -decrypt -binary -in encrypted.zip.enc -inform DER -out decrypted.zip -inkey private.key -passin pass:ВАШ-ПАРОЛЬ

В этой команде:

• -inform DER — то же самое, что и в -outform выше
• -inkey private.key — имя файла вашего приватного ключа. Он должен быть в формате PEM и может быть зашифрован паролем.
• -passin pass:ВАШ-ПАРОЛЬ — ваш пароль для зашифрованного приватного ключа.

Итак, при симметричном шифровании нужно выбрать хороший алгоритм шифроания и не забыть указать большое количество итераций. А для асимметричного шифрования имеются ограничения и костыли. По этой причине вновь рекомендуется использовать gpg:

Инструкции для генерации запроса подписи сертификата (csr) с алгоритмом шифрования ecc на сервере microsoft windows 2008 server.

Посмотрите видео-демонстрацию для создания CSR с алгоритмом шифрования ECC на сервере Microsoft Windows 2008

Шаг 1. Создание оснастки для сертификатов в консоли управления Microsoft

1. Нажмите кнопку «Пуск» и выполните поиск MMC
2. В окне MMC выберите «Файл»> «Добавить / удалить оснастку»
3. Выберите «Сертификаты» в левом столбце
4. Нажмите Добавить
5. Когда появится мастер оснастки «Сертификат», выберите «Учетная запись компьютера»
6. Нажмите «Далее»
7. Выбор локального компьютера
8. Нажмите Готово
9. Подтвердить сертификат появится в правой колонке
10. Нажмите ОК.

Шаг 2 Создание файла CSR из хранилища личных сертификатов в MMC

1. В окне MMC опустите дерево сертификатов
2. Щелкните правой кнопкой мыши личную папку
3. Выберите «Все задачи> Дополнительные операции»> «Создать пользовательский запрос».
4. В мастере регистрации сертификатов нажмите «Далее».
5. Выбрать Продолжить без политики регистрации
6. Нажмите «Далее»
7. В разделе «Шаблон» выберите (Без шаблона) СCNG-ключ
8. В разделе Формат запроса выберите PKCS # 10
9. Нажмите «Далее»
10. Когда появится окно «Информация о сертификате», нажмите стрелку раскрывающегося списка рядом с «Подробности»
11. Щелкните Свойства
12. Введите дружественное имя
    
    ПРИМЕЧАНИЕ . Дружественное имя в основном используется для указания отдела или фиктивного имени, чтобы помочь
    идентифицировать сертификат на сервере.
13. Перейдите на вкладку Тема.
14. Выбросьте меню для «Тип» и введите информацию в поле «Значение», нажав кнопку «Добавить» , когда каждое поле будет завершено.
    Сделайте это для следующих полей:
    • Общее имя: полное доменное имя, на которое будет выдан ваш сертификат.
    • Страна. Введите двухзначную аббревиатуру страны, в которой находится организация (например, UA).
    • Город: Обычно это главный офис вашей организации или главный офис вашей организации.
    • Организация: полное юридическое название вашей компании.
    • Организационное подразделение: используйте это поле для разграничения между подразделениями внутри организации.
    • State: Введите полное имя вашей области.
      
      Примечание. Убедитесь, что название области не сокращено не сокращены (например, Khmelnitska).
15. Перейдите на вкладку «Частный ключ»
16. Нажмите стрелку раскрывающегося списка рядом с поставщиком криптографических услуг
17. Снимите флажок, выбранный по умолчанию для RSA
18. Установите флажок для ECDH_P256
    
    ПРИМЕЧАНИЕ. На момент публикации этого документа DigiCert в настоящее время поддерживает только эллиптическую кривую ECDH_P256
    для серверов Microsoft. – уточните информацию на сегодня
19. Нажмите стрелку раскрывающегося списка рядом с параметрами клавиш
20. Установите флажок Сделать доступным закрытый ключ
    
    ПРИМЕЧАНИЕ. Этот параметр позволяет резервировать или экспортировать сертификат с сервера.
21. Нажмите Применить> ОК.
22. В мастере регистрации сертификатов нажмите «Далее».
23. Нажмите Обзор
24. В окне «Сохранить как» перейдите к местоположению для сохранения файла
25. Введите имя файла
26. Нажмите Сохранить.
27. В мастере регистрации сертификатов выберите Base 64
28. Нажмите Готово

ECC CSR теперь создан. При открытии файла CSR убедитесь, что используется только приложение для текстового редактора (например, Блокнот или Vi).

Как добавить корневой сертификат в доверенные в linux на уровне системы

Сертификат с расширением .crt можно открыть двойным кликом и просмотреть его содержимое:

Если вы работаете в системе от обычного пользователя (не root), то кнопка «Импортировать» будет недоступна.

Чтобы разблокировать кнопку «Импортировать», выполните следующую команду:

sudo gcr-viewer /ПУТЬ/ДО/СЕРТИФИКАТА.crt

Например:

sudo gcr-viewer ./HackWareCA.crt

Данный способ может не сработать, поэтому рассмотрим, как добавить доверенные корневые центры сертификации в командной строке.

Суть метода очень проста:

1. Добавить свой корневой CA сертификат в папку, предназначенную для таких сертификатов.
2. Запустить программу для обновления общесистемного списка сертификатов.

Пути и команды в разных дистрибутивах Linux чуть различаются.

Просмотреть Subject всех корневых CA сертификатов можно уже знакомой командой:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt

Для демонстрации я добавлю сертификат с Common Name, включающим «HackWare», тогда для проверки, имеется ли сертификат с таким именем среди корневых CA, я могу использовать команду:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare

Для добавления своего корневого CA в доверенные в Debian, Kali Linux, Linux Mint, Ubuntu и их производных:

1. Проверьте, существует ли директория /usr/local/share/ca-certificates:

ls -l /usr/local/share/ca-certificates

Если её ещё нет, то создайте:

sudo mkdir /usr/local/share/ca-certificates

Сертификат должен быть в формате PEM (обычно так и есть) и иметь расширение .crt — если расширение вашего сертификата .pem, то достаточно просто поменять на .crt.

2. Скопируйте ваш сертификат командой вида:

sudo cp СЕРТИФИКАТ.crt /usr/local/share/ca-certificates/

Например:

sudo cp ./HackWareCA.crt /usr/local/share/ca-certificates/

3. Запустите следующую команду для обновления общесистемного списка:

sudo update-ca-certificates

Пример вывода:

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Adding debian:HackWareCA.pem
done.
done.

Проверим наличие нашего CA сертификата среди доверенных:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare

Сертификат успешно найден:

Чтобы его удалить:

sudo rm /usr/local/share/ca-certificates/СЕРТИФИКАТ.crt
sudo update-ca-certificates

Для добавления своего корневого CA в доверенные в Arch Linux, BlackArch и их производных:

1. Выполните команду вида:

sudo cp ./СЕРТИФИКАТ.crt /etc/ca-certificates/trust-source/anchors/

Например:

sudo cp ./HackWareCA.crt /etc/ca-certificates/trust-source/anchors/

2. Обновите общесистемный список доверенных CA:

sudo update-ca-trust

Чтобы удалить этот сертификат:

sudo rm /etc/ca-certificates/trust-source/anchors/СЕРТИФИКАТ.crt
sudo update-ca-trust

Добавление сертификатов в базу данных NSS

Некоторые приложения используют базу данных NSS, и у вас может быть необходимость добавить доверенные CA в неё.

Последующие изменения повлияют только на приложения, использующие базу данных NSS и учитывающие файл /etc/pki/nssdb.

1. Сначала создайте структуру каталогов для системных файлов базы данных NSS:

sudo mkdir -p /etc/pki/nssdb

Затем создайте новый набор файлов базы данных. Пароль нужен для того, чтобы базу данных могли редактировать только люди, которые его знают. Если все пользователи в системе (и с доступом к резервным копиям) заслуживают доверия, этот пароль можно оставить пустым.

sudo certutil -d sql:/etc/pki/nssdb -N

2. Убедитесь, что файлы базы данных доступны для чтения всем:

sudo chmod go r /etc/pki/nssdb/*

3. Теперь, когда доступны файлы базы данных NSS, добавьте сертификат в хранилище следующим образом:

sudo certutil -d sql:/etc/pki/nssdb -A -i ФАЙЛ-СЕРТИФИКАТА.crt -n "ИМЯ-СЕРТИФИКАТА" -t "C,,"

Например:

sudo certutil -d sql:/etc/pki/nssdb -A -i ./HackWareCA.crt -n "HackWare CA" -t "C,,"

Биты доверия, используемые в приведённом выше примере, помечают сертификат как надёжный для подписи сертификатов, используемых для связи SSL/TLS. Имя (указывается после опции -n), используемое в команде, можно выбрать любое, но убедитесь, что его легко отличить от других сертификатов в магазине.

Для проверки:

certutil -L -d /etc/pki/nssdb

Аналогичные инструкции можно использовать для включения сертификата только в базу данных NSS конкретного пользователя:

certutil -d sql:$HOME/.pki/nssdb -A -i ФАЙЛ-СЕРТИФИКАТА.crt -n "ИМЯ-СЕРТИФИКАТА" -t "C,,"

Удаление из файлов базы данных NSS

Чтобы удалить сертификат из любой базы данных NSS, используйте команду certutil следующим образом. В этом примере используется общесистемное расположение базы данных NSS, но его можно легко изменить на пользовательское ~/.pki/nssdb местоположение.

sudo certutil -d sql:/etc/pki/nssdb -D -n "certificateName"

Как пользоваться openssl (команды openssl)

Команды OpenSSL не столько сложные, сколько запутанные.

Во-первых, их много (48 основных команд, 28 digest команд, 84 cipher команды, а также алгоритмы и методы), некоторые из них выполняют более чем одну функцию, некоторые имеют пересекающиеся функции и не всегда непонятно, какую команду выбрать.

Синтаксис использования команд OpenSSL:

openssl КОМАНДА ОПЦИИ

Ещё один пример как команды OpenSSL могут сбить с толку: у команды x509 есть опция -req, а у команды req есть опция -x509.

Если вы хотите получить справку по командам OpenSSL, то вам нужно знать, что это делается так:

man openssl-КОМАНДА
# ИЛИ
man КОМАНДА

Например:

man openssl-req
man openssl-x509
man openssl-genpkey
man openssl-enc
man openssl-rsa
# ИЛИ
man req
man x509
man genpkey
man enc
man rsa

При этом если по аналогии попытаться использовать в командной строке openssl-req или req, то такие команды будет не найдены (нужно использовать openssl req …).

Команды openssl могут быть громоздкими за счёт того, что через одну из опций команды передаются опции сертификата.

На самом деле, для типичных задач используется всего несколько команд и несколько опций. Поэтому если понимать суть, то всё довольно просто.

Перечень команд OpenSSL, которые мы будем использовать:

• genpkey (заменяет genrsa, gendh и gendsa) — генерирует приватные ключи
• req — утилита для создания запросов на подпись сертификата и для создания самоподписанных сертификатов PKCS#10
• x509 — утилита для подписи сертификатов и для показа свойств сертификатов
• rsa — утилита для работы с ключами RSA, например, для конвертации ключей в различные форматы
• enc — различные действий с симметричными шифрами
• pkcs12 — создаёт и парсит файлы PKCS#12
• crl2pkcs7 — программа для конвертирования CRL в PKCS#7
• pkcs7 — выполняет операции с файлами PKCS#7 в DER или PEM формате
• verify — программа для проверки цепей сертификатов
• s_client — команда реализует клиент SSL/TLS, который подключается к удалённому хосту с использованием SSL/TLS. Это очень полезный инструмент диагностики для серверов SSL
• ca — является минимальным CA-приложением. Она может использоваться для подписи запросов на сертификаты в различных формах и генерировать списки отзыва сертификатов. Она также поддерживает текстовую базу данных выданных сертификатов и их статус
• rand — эта команда генерирует указанное число случайных байтов, используя криптографически безопасный генератор псевдослучайных чисел (CSPRNG)
• rsautl — команда может быть использована для подписи, проверки, шифрования и дешифрования данных с использованием алгоритма RSA
• smime — команда обрабатывает S/MIME почту. Она может шифровать, расшифровывать, подписывать и проверять сообщения S/MIME

Чтобы увидеть полный список команд выполните:

openssl list -commands

Пример вывода:

asn1parse         ca                ciphers           cms               
crl               crl2pkcs7         dgst              dhparam           
dsa               dsaparam          ec                ecparam           
enc               engine            errstr            gendsa            
genpkey           genrsa            help              list              
nseq              ocsp              passwd            pkcs12            
pkcs7             pkcs8             pkey              pkeyparam         
pkeyutl           prime             rand              rehash            
req               rsa               rsautl            s_client          
s_server          s_time            sess_id           smime             
speed             spkac             srp               storeutl          
ts                verify            version           x509

Как решить проблему

В первую очередь стоит удостовериться, что КС корректно установлен и действителен. Для этого используется стандартный путь: «Пуск» → «Все программы» → «КриптоПро» → «Сертификаты» → «Доверенные центры сертификации» → «Реестр». В открывшемся списке должен быть документ от ПАК «Минкомсвязь России». Если сертификат отсутствует или он недействителен, его нужно установить, следуя алгоритму:

1. Открыть загруженный файл на ПК.
2. Во вкладке «Общие» кликнуть «Установить».
3. Поставить флажок напротив строчки «Поместить в следующее хранилище».
4. Выбрать хранилище «Доверенные корневые центры сертификации».
5. Продолжить установку кнопкой «ОК» и подтвердить согласие в окне «Предупреждение о безопасности».

После установки появится сообщение, что импорт успешно завершен. Далее рекомендуется перезагрузить компьютер.

Файл выдается удостоверяющим центром вместе с другими средствами для формирования ЭЦП. Если он утерян или удален, следует обратиться в УЦ, в котором был получен СКПЭП.

Если КС Минкомсвязи на месте, но в статусе по-прежнему сказано, что он недействителен, удалите его (выбрать файл и нажать «Удалить») и установите заново.

На форуме CryptoPro CSP предлагается еще один вариант решения проблемы. Но работает он не всегда. Если установка документа не помогла, откройте меню «Пуск» и выполните поиск редактора реестра по его названию regedit. В редакторе найдите и вручную удалите следующие ветки:

Не все ветки могут быть в наличии. Удалите те, что есть, предварительно сохранив их резервные копии в отдельный файл. Перезагрузите ПК и проверьте статус СКЭП — он должен стать действительным.

Важно! Удаление и редактирование ключей реестра может нарушить работоспособность системы, поэтому процедуру лучше доверить техническому специалисту.

Общесистемные корневые ca сертификаты

Если вы задаётесь вопросом, в какой папке хранятся сертификаты в Windows, то правильный ответ в том, что в Windows сертификаты хранятся в реестре. Причём они записаны в виде бессмысленных бинарных данных. Чуть ниже будут перечислены ветки реестра, где размещены сертификаты, а пока давайте познакомимся с программой для просмотра и управления сертификатами в Windows.

В Windows просмотр и управление доверенными корневыми сертификатами осуществляется в программе Менеджер Сертификатов.

Чтобы открыть Менеджер Сертификатов нажмите Win r, введите в открывшееся поле и нажмите Enter:

certmgr.msc

Перейдите в раздел «Доверенные корневые центры сертификации» → «Сертификаты»:

Здесь для каждого сертификата вы можете просматривать свойства, экспортировать и удалять.

Просмотр сертификатов в PowerShell

Чтобы просмотреть список сертификатов с помощью PowerShell:

Get-ChildItem cert:LocalMachineroot | format-list

Чтобы найти определённый сертификат выполните команду вида (замените «HackWare» на часть искомого имени в поле Subject):

Get-ChildItem cert:LocalMachineroot | Where {$_.Subject -Match "HackWare"} | format-list

Теперь рассмотрим, где физически храняться корневые CA сертификаты в Windows. Сертификаты хранятся в реестре Windows в следующих ветках:

Сертификаты уровня пользователей:

Сертификаты уровня компьютера:

• HKEY_LOCAL_MACHINESoftwareMicrosoftSystemCertificates — содержит настройки для всех пользователей компьютера
• HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificates — как и предыдущее расположение, но это соответствует сертификатам компьютера, развёрнутым объектом групповой политики (GPO (Group Policy))

Сертификаты уровня служб:

• HKEY_LOCAL_MACHINESoftwareMicrosoftCryptographyServicesServiceNameSystemCertificates — содержит настройки сертификатов для всех служб компьютера

Сертификаты уровня Active Directory:

• HKEY_LOCAL_MACHINESoftwareMicrosoftEnterpriseCertificates — сертификаты, выданные на уровне Active Directory.

И есть несколько папок и файлов, соответствующих хранилищу сертификатов Windows. Папки скрыты, а открытый и закрытый ключи расположены в разных папках.

Пользовательские сертификаты (файлы):

Компьютерные сертификаты (файлы):

• C:ProgramDataMicrosoftCryptoRSAMachineKeys

Рассмотрим теперь где хранятся корневые CA сертификаты веб-браузеров.

Проблема устаревших корневых сертификатов. на очереди let’s encrypt и умные телевизоры

Чтобы браузер мог аутентифицировать веб-сайт, тот представляет себя действительной цепочкой сертификатов. Типичная цепочка показана сверху, в ней может быть больше одного промежуточного сертификата. Минимальное количество сертификатов в действительной цепочке равно трём.

Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве. Его не поменяешь со стороны сервера. Нужно принудительное обновление ОС или встроенного ПО на устройстве.

Специалист по безопасности Скотт Хельме (Scott Helme) пишет, что основные проблемы возникнут у центра сертификации Let’s Encrypt, потому что сегодня это самый популярный ЦС в интернете, а его корневой сертификат скоро «протухнет». Смена корня Let’s Encrypt назначена на 8 июля 2020 года.

Про сертификаты:  NOVACOL 2K 50 | Научно - производственное - предприятие "НОВАКОЛ"

Конечные и промежуточные сертификаты удостоверяющего центра (CA) доставляются клиенту с сервера, а корневой сертификат у клиента уже есть, поэтому с помощью этой коллекции сертификатов можно построить цепочку и аутентифицировать веб-сайт.

Проблема заключается в том, что у каждого сертификата есть срок действия, после чего он нуждается в замене. Например, с 1 сентября 2020 года в браузере Safari планируют ввести ограничение на срок действия серверных TLS-сертификатов максимум 398 дней.

Это значит, что всем нам придётся заменять серверные сертификаты по крайней мере каждые 12 месяцев. Это ограничение распространяется только на сертификаты сервера, оно не распространяется на корневые сертификаты CA.

Сертификаты CA регулируются другим набором правил, поэтому имеют разные ограничения на срок действия. Очень часто встречаются промежуточные сертификаты со сроком действия 5 лет и корневые сертификаты со сроком службы даже 25 лет!

С промежуточными сертификатами обычно нет проблем, потому что они поставляются клиенту сервером, который сам гораздо чаще меняет свой собственный сертификат, так что просто в ходе этой процедуры заменяет и промежуточный. Его довольно легко заменить вместе с сертификатом сервера, в отличие от корневого сертификата CA.

Как мы уже говорили, корневой CA встроен непосредственно в само клиентское устройство, в ОС, в браузер или другое программное обеспечение. Изменение корневого CA веб-сайт не может контролировать. Здесь требуется обновление на клиенте, будь то обновление ОС или софта.

Некоторые корневые CA существуют уже очень давно, речь о 20-25 годах. Скоро некоторые из самых старых корневых CA приблизятся к концу своей естественной жизни, их время почти истекло. Для большинства из нас это вообще не будет проблемой, потому что CA создали новые корневые сертификаты, и они уже много лет распространяются по всему миру в обновлениях ОС и браузеров. Но если кто-то очень давно не обновлял ОС или браузер, это своего рода проблема.

Такая ситуация возникла 30 мая 2020 года в 10:48:38 GMT. Это точное время, когда протух корневой сертификат AddTrust от центра сертификации Comodo (Sectigo).

Он использовался для перекрёстной подписи, чтобы обеспечить совместимость с устаревшими устройствами, в хранилище которых нет нового корневого сертификата USERTrust.

К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.

Предполагалось, что проблема затронет только устаревшие системы (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 и т.п.), поскольку современные браузеры могут задействовать второй корневой сертификат USERTRust. Но по факту начались сбои в сотнях веб-сервисов, которые использовали свободные библиотеки OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата.

Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё

в апреле 2021 года

они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого

не произошло

.

«Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2021 года на 8 июля 2020 года», — сказано в официальном сообщении Let’s Encrypt.

Дату пришлось перенести из-за проблемы, которую называют «распространением корня» (root propagation), а точнее, отсутствием распространения корня, когда корневой CA не слишком широко распространён на всех клиентах.

Сейчас Let’s Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let’s Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1.

Корень ISRG выпущен 4 июня 2021 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2021 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.

Но в этом и проблема.

Если ваш мобильный телефон, телевизор или другое устройство не обновлялось два года — как оно узнает о новом корневом сертификате ISRG Root X1? А если его не установить в системе, то все серверные сертификаты Let’s Encrypt ваше устройство признает недействительными, как только Let’s Encrypt перейдёт на новый корень. А в экосистеме Android много устаревших устройств, которые давно не обновлялись.

Экосистема Android

Вот почему Let’s Encrypt отложил переход к собственному корню ISRG и всё ещё использует промежуточное звено, которое спускается к корню IdenTrust. Но переход в любом случае придётся сделать. И датой смены корня назначено 8 июля 2020 года.

Для проверки, что на вашем устройстве (телевизор, приставка или другой клиент) установлен корень ISRG X1, откройте тестовый сайт https://valid-isrgrootx1.letsencrypt.org/. Если не появляется предупреждение безопасности, то обычно всё в порядке.

Let’s Encrypt не единственный, кому предстоит решить проблему с переходом на новый корень. Криптографию в интернете начали использовать чуть более 20 лет назад, так что как раз сейчас наступает момент окончания действия многих корневых сертификатов.

С такой проблемой могут столкнуться владельцы умных телевизоров, которые много лет не обновляли программное обеспечение Smart TV. Например, новый корень GlobalSign R5 Root выпущен в 2021 году, и после некоторые старые Smart TV не могут построить цепочку к нему, потому что этот корневой CA у них просто отсутствует. В частности, эти клиенты не могли установить защищённое соединение с сайтом bbc.co.uk. Чтобы решить проблему, админам BBC пришлось пойти на хитрость: они построили для этих клиентов альтернативную цепочку через дополнительные промежуточные сертификаты, задействуя старые корни R3 Root и R1 Root, которые ещё не протухли.

www.bbc.co.uk (Leaf)
GlobalSign ECC OV SSL CA 2021 (Intermediate)
GlobalSign Root CA - R5 (Intermediate)
GlobalSign Root CA - R3 (Intermediate)

Это временное решение. Проблема никуда не уйдёт, если не обновить клиентское ПО. Умный телевизор — это по сути ограниченный в функциональности компьютер под Linux. И без обновлений его корневые сертификаты неизбежно протухнут.

Это касается всех устройств, не только телевизоров. Если у вас любое устройство, которое подключено к интернету и которое рекламировали как «умный» девайс, то проблема с протухшими сертификатами почти наверняка касается его. Если устройство не обновляется, то корневое хранилище CA со временем устареет, и в конечном итоге проблема всплывёт на поверхность. Как скоро возникнет проблема, зависит от времени последнего обновления корневого хранилища. Это может быть за несколько лет до даты реального выпуска устройства.

Кстати, в этом проблема, почему некоторые крупные медиаплатформы не могут использовать современные автоматизированные центры сертификации типа Let’s Encrypt, пишет Скотт Хельме. Для умных ТВ они не подходят, и количество корней слишком мало, чтобы гарантировать поддержку сертификата на устаревших устройствах. В противном случае ТВ просто не сможет запустить современные стриминговые сервисы.

Последний инцидент с AddTrust показал, что даже крупные IT-компании бывают не готовы к тому, что у корневого сертификата заканчивается срок действия.

Решение проблемы только одно — обновление. Разработчики умных устройств должны заранее обеспечить механизм обновления программного обеспечения и корневых сертификатов. С другой стороны, производителям невыгодно обеспечивать работу своих устройств по окончании срока гарантии.

---

Редактирования ключей gpg

Для редактирования ключа определённого пользователя выполните команду (замените ‘Alexey Miloserdov’ на желаемый идентификатор пользователя):

gpg --edit-key 'Alexey Miloserdov'

Вы попадёте в интерактивный интерфейс командной строки, там будут работать следующие команды:

quit        выйти из этого меню
save        сохранить и выйти
help        показать данную справку
fpr         показать отпечаток ключа
grip        показать код ключа
list        вывести список ключей и идентификаторов пользователя
uid         выбрать идентификатор пользователя N
key         выбрать подключ N
check       проверка подписей
sign        подписать выбранные идентификаторы пользователя [* описание команд см. ниже]
lsign       локально подписать выбранные идентификаторы пользователя
tsign       подписать выбранные идентификаторы пользователя подписью доверия
nrsign      подписать выбранные идентификаторы пользователя без возможности отзыва
adduid      добавить идентификатор пользователя
addphoto    добавить фотоидентификатор
deluid      удалить выбранные идентификаторы пользователя
addkey      добавить подключ
addcardkey  добавить ключ на криптографическую карту
keytocard   переместить ключ на криптографическую карту
bkuptocard  переместить архивный ключ на криптографическую карту
delkey      удалить выбранные подключи
addrevoker  добавить ключ отзыва
delsig      удалить подписи с выбранных идентификаторов пользователя
expire      сменить срок действия ключа или выбранных подключей
primary     пометить выбранный идентификатор пользователя как первичный
pref        список предпочтений (экспертам)
showpref    список предпочтений (подробный)
setpref     установить список предпочтений для выбранных идентификаторов пользователя
keyserver   установить URL предпочтительного сервера ключей для выбранных идентификаторов пользователя
notation    установить замечание для выбранных идентификаторов пользователя
passwd      сменить фразу-пароль
trust       изменить уровень доверия владельцу
revsig      отозвать подписи у выбранных идентификаторов пользователя
revuid      отозвать выбранные идентификаторы пользователя
revkey      отозвать ключ или выбранные подключи
enable      подключить ключ
disable     отключить ключ
showphoto   показать выбранные фотоидентификаторы
clean       сжать непригодные идентификаторы пользователей и удалить непригодные подписи из ключа
minimize    сжать непригодные идентификаторы пользователей и удалить все подписи из ключа

* У команды 'sign' может быть приставка 'l' (локальные подписи, lsign),
  't' (подписи доверия, tsign), 'nr' (неотзываемые, 
  nrsign) или любое их сочетание (ltsign, tnrsign и т.д.).

Сертификаты типа «production»

Для начала на всякий случай поясню, что сборкой iOS-приложения называют *.ipa-файл, архив, выпускаемый с соблюдением правил сертификации Apple через команду Project — Archive в Xcode.

Теперь о сертификации. Прод-сертификаты обеспечивают функционирование различных подсистем приложения в «боевых» условиях, то есть в магазине App Store, а также на устройствах, где выполняется внутреннее и внешнее тестирование приложения через TestFlight.

Здесь, по аналогии с Development-сертификацией, есть тип App Store & Ad Hoc Production, а также тип APNs Production, использующийся веб-сервером для рассылки push-уведомлений. Если вы планируете выпустить приложение, поддерживающее работу с пушами, то вам понадобятся оба сертификата, как App Store &

Ad Hoc (на основе которого вы сделаете сборку и отправите приложение в iTunes Connect), так и APNs Production (его вы отдадите серверу, а тот воспользуется им для получения прав на рассылку пушей). В довесок к уже упомянутым подсистемам есть еще несколько других, обеспечивающих доступ к Wallet, Apple Watch и так далее, но их обзор выходит за рамки данной статьи.

Очень часто возникает вопрос о том, в чем же разница между App Store и тем самым Ad Hoc. Ранее они были представлены разными сертификатами, с некоторого времени Apple объединила их в единое целое, за что им большое спасибо. Чуть подробнее об этих разновидностях:

• Выпуск сборок типа App Store. Обеспечивает возможность тестировать приложение в TestFlight, как в режиме внутреннего, так и в режиме внешнего тестирования. Также дает возможность опубликовать приложение в App Store.
• Выпуск сборок типа Ad Hoc. Термин «Ad Hoc» можно перевести как «специальный», «для конкретной цели». Такой тип сертификации обеспечивает возможность запускать ваше приложение (включая все нужные подсистемы типа APNs) в боевых условиях, но только на конкретных девайсах, и без участия Xcode в процессе запуска. Другими словами, Ad Hoc необходим, если вы захотите поставить ваше приложение на стороннее устройство, не имея к нему прямого доступа (то есть не подсоединяя его проводом к вашему Mac, так как в этом случае вам бы хватило Development-сертификата), но при этом и не выкладывая приложение в iTunes Connect. Такой сертификат используется при создании специального Ad Hoc-профиля, о котором пойдет речь чуть позже.

Еще один частый вопрос: чем отличаются сборки, собранные на паре Development Certificate Development Profile, и сборки, созданные через связку Distribution Certificate Ad Hoc Profile? Ведь и там, и там нужно указывать перечень разрешенных для установки устройств, и то, и то можно устанавливать через iTunes.

В чем же различие? На деле, разница в том, что дев-сборка будет запускаться «в отладочном режиме», то есть, например, APNs ей будут доступны только в режиме «sandbox». Продакшн-сборка будет обладать «боевыми» правами, с доступом во все подсистемы Apple вроде «настоящих» APNs, iCloud и так далее.

Симметричное шифрование файлов в openssl

Данный вид шифрования выполняется командой enc. Кстати она также задействуется при создании ключей, если выбрано их шифрование — это шифрование выполняется с помощью enc.

Для шифрования используется команда следующего вида:

openssl enc -ШИФР -in ДЛЯ-ШИФРОВАНИЯ -out ЗАШИФРОВАНЫЕ-ДАННЫЕ

Для расшифровки похожая команда, но с опцией -d, также ЗАШИФРОВАНЫЕ-ДАННЫЕ теперь являются входными, а на выходе РАСШИФРОВАННЫЕ-ДАННЫЕ:

openssl enc -ШИФР -d -in ЗАШИФРОВАНЫЕ-ДАННЫЕ -out РАСШИФРОВАННЫЕ-ДАННЫЕ

В качестве ШИФРА рекомендуют aes-256-cbc, а полный список шифров вы можете посмотреть командой:

openssl enc -list

Ещё настоятельно рекомендуется использовать опцию -iter ЧИСЛО. Она использует указанное ЧИСЛО итераций для пароля при получении ключа шифрования. Высокие значения увеличивают время, необходимое для взлома пароля брут-форсом зашифрованного файла.

Эта опция включает использование алгоритма PBKDF2 для получения ключа. Указывать можно высокие значения — десятки и сотни тысяч. В разделе «Как создать базу данных KeePass» при создании базы данных используется такой же алгоритм (первая версия), там для 1 секундной задержки я выставлял значение в 25 миллионов инераций.

Пример шифрования файла art.txt шифром aes-256-cbc, зашифрованные данные будут помещены в файл с именем art.txt.enc, при получении ключа шифрования используется десять миллионов итераций (на моём железе выполнение команды заняло несколько секунд):

openssl enc -aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000

Введите, а затем подтвердите пароль для шифрования:

В результате будет создан зашифрованный файл art.txt.enc.

Для расшифровки файла art.txt.enc и сохранения данных в файл art-new.txt:

openssl enc -aes-256-cbc -d -in art.txt.enc -out art-new.txt -iter 10000000

Если файл успешно расшифрован, то не будет выведена никакая дополнительная информация.

В случае неудачной расшифровки будет показано примерно следующее:

bad decrypt
140381536523584:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:583:

Возможные причины ошибки:

• неверный пароль
• неверный алгоритм для расшифровки
• неправильно указано количество итераций с опцией -iter
• неверно указан файл для расшифровки

Обратите внимание, что для расшифровки также нужно указать опцию -iter с тем же самым значением, которое было указано при шифровании. Конечно, можно не использовать опцию -iter при шифровании (а, следовательно, и при расшифровке), но в этом случае шифрование считается ненадёжным!

Не рекомендуется пропускать опцию. Если у вас слабое железо ИЛИ если файл будет расшифровываться на слабом железе, то вам необязательно использовать такие большие значения -iter — укажите хотя бы десятки или сотни тысяч (например, полмиллиона).

Предыдущие команды для шифрования и расшифровки могут запускаться чуть иначе:

openssl ШИФР

Например:

openssl aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000

То есть пропускается слово enc, и перед шифром убирается дефис. Обе команды равнозначны.

Зашифрованный файл представляет собой бинарные данные, которые не получится передать, например, в текстовом сообщении (в чате). Используя опцию -a (или её псевдоним -base64), можно закодировать зашифрованные данные в кодировку Base64:

openssl enc -aes-256-cbc -in art.txt -out art.txt.b64 -iter 10000000 -a

Содержимое полученного файла art.txt.b64 можно открыть любым текстовым редактором и переслать в мессенджере или в чате.

Для расшифровки также нужно указать опцию -a:

openssl enc -aes-256-cbc -d -in art.txt.b64 -out art-new.txt -iter 10000000 -a

Чтобы просто закодировать бинарный файл в кодировку base64:

openssl enc -base64 -in file.bin -out file.b64

Чтобы раскодировать этот файл:

openssl enc -base64 -d -in file.b64 -out file.bin

Чтобы зашифровать файл используя указанный ПАРОЛЬ в команде (не интерактивный режим):

openssl enc -aes128 -pbkdf2 -d -in file.aes128 -out file.txt -pass pass:ПАРОЛЬ

Зашифровать файл, затем закодировать его с помощью base64 (например, его можно отправить по почте), используя AES-256 в режиме CTR и с получением производной ключа PBKDF2:

openssl enc -aes-256-ctr -pbkdf2 -a -in file.txt -out file.aes256

Декодировать файл из Base64 , затем расшифровывать его, используя пароль, указанный в файле:

openssl enc -aes-256-ctr -pbkdf2 -d -a -in file.aes256 -out file.txt -pass file:<ФАЙЛ-С-ПАРОЛЕМ>

Шифрование файлов и данных с gpg

Про шифрование в gpg нужно знать, что оно может быть:

• ассиметричным (шифруется публичным ключом, расшифровывается приватным)
• симметричным (шифруется и расшифровывается приватным ключом, шифруется и расшифровывается одной и той же парольной фразой)

Второе, что нужно знать: шифрование можно совмещать с подписыванием файла. Подписывание файла и проверку подписи мы рассмотрим далее. Также далее мы рассмотрим одновременное шифрование и подпись файла.

Третье: зашифровать можно одним или более публичными ключами.

Для шифрования файла используя симметричный метод с паролем используйте опцию -c (либо её длинный аналог –symmetric):

Следующая команда для шифрования файла test.php паролем в gpg:

gpg -c test.php

В результате шифрования будет создан файл с расширением .gpg (в данном случае это будет файл test.php.gpg).

Для того, чтобы зашифровать файл симметричным шифрованием с возможностью расшифровки приватным ключом (в этом случае его можно будет расшифровать приватным ключом, либо паролем) нужно использовать сразу несколько опций:

• -e — означает шифрование данных
• -c — означает симметричное шифрование
• -r ‘id’ — означает зашифровать данные для пользователя с определённым id

Пример команды симметричного шифрования файла test.php для пользователя Alexey Miloserdov с возможностью его расшифровки приватным ключом ЛИБО для расшифровки паролем:

gpg -e -c -r 'Alexey Miloserdov' test.php

Точнее говоря, комбинирование двух опций -e и -c шифрует ключ сессии публичным ключом и симметричным шифром, поэтому для расшифровки может использоваться И приватный ключ, И пароль (на выбор). Если на другом компьютере, где вы расшифровываете файл, имеется ваш приватный ключ, то при расшифровке будет запрошен пароль приватного ключа. Если приватный ключ отсутствует, то будет запрошен пароль, который использовался при шифровании файла.

Для шифрования публичным ключом (-e), чтобы файл (test.php) мог расшифровать только владелец соответствующего парного приватного ключа (-r ‘Alexey Miloserdov’):

gpg -e -r 'Alexey Miloserdov' test.php

Вместо опции -r ‘Имя Адресата’ можно использовать опцию -R ‘Имя Адресата’ или её длинный аналог –hidden-recipient ‘Имя Адресата’. Она также шифрует файл для указанного адресата, но имя этого адресата шифруется.

Пример шифрования файла test.php публичным ключом пользователя Alexey Miloserdov, но с зашифрованным именем адресата.

gpg -e -R 'Alexey Miloserdov' test.php

Обратите внимание, что во всех случаях шифрования оригинальный файл остаётся!!! Вам самим нужно решать, что с ним делать, например, удалить его.

Чтобы каждый раз не вводить имя получателя, можно установить значение по умолчанию опцией –default-recipient. Также с ней в комплекте идут опции –default-recipient-self и –no-default-recipient.