Это означает что openssl на вашем сервере не может проверить сертификат хоста

Шифрование файлов в OpenSSL

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

Для шифрования файлов вместо OpenSSL рекомендуется использовать инструмент gpg. С этим инструментом вы можете познакомиться в статье «Как пользоваться gpg: шифрование, расшифровка файлов и сообщений, подпись файлов и проверка подписи, управление ключами».

Симметричное шифрование файлов в 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 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 (симметричное шифрование)

Следует помнить, что для шифрования используется весь набор символов ASCII, включая непечатаемые символы. Если вы хотите иметь возможность вырезать и вставлять зашифрованные данные из консоли или текстового файла, вам нужно преобразовать их только в печатные символы. Вы можете сделать это с опцией -base64 (или -a):

Расшифровка делается таким же образом (нужно дополнительно указать опцию -d):

ВНИМАНИЕ: Если вы используете openssl, то можно предположить, что конфиденциальность данных и, следовательно, пароль, важны для вас. Если это так, вы никогда не должны указывать пароль в командной строке, потому что он может быть показан любому, кто имеет право запускать ps (смотрите Как использовать команду ps для мониторинга процессов Linux).

Лучшее решение — сохранить пароль в переменной окружения и открыть его с помощью openssl:

Асимметричное шифрование файлов в OpenSSL

Необходимо сгенерировать приватный ключ и извлечь из него публичный ключ. Публичным ключом данные будут шифроваться, а приватным ключом — расшифровываться. Команды для генерации ключей уже рассмотрены выше, напомним их (в данном случае приватный ключ будет сохранён в файл private.key):

Для извлечения публичного ключа в файл (public.key) из приватного ключа (private.key):

openssl rsa -in private.key -pubout -out public.key

Для шифрования файла:

openssl rsautl -encrypt -pubin -inkey ПУБЛИЧНЫЙ-КЛЮЧ.key -in ЗАШИФРОВАТЬ.txt -out ЗАШИФРОВАНО.txt

openssl rsautl -decrypt -inkey ПРИВАТНЫЙ-КЛЮЧ.key -in ЗАШИФРОВАНО.txt -out РАСШИФРОВАНО.txt

Описанным методом невозможно зашифровать большие файлы!

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

Ассиметричное шифрование для симметричного ключа

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

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

openssl enc -aes-256-cbc -in БОЛЬШОЙ-ФАЙЛ -out БОЛЬШОЙ-ФАЙЛ.enc -pass file:./key.bin

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

openssl rsautl -encrypt -inkey public.pem -pubin -in key.bin -out key.bin.enc

Удаляем незашифрованный симметричный ключ, чтобы никто его не узнал:

shred -u key.bin

Теперь отправляем зашифрованный симметричный ключ (key.bin.enc) и зашифрованный большой файл (БОЛЬШОЙ-ФАЙЛ.enc) другому лицу.

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

openssl rsautl -decrypt -inkey private.pem -in key.bin.enc -out key.bin

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

openssl enc -d -aes-256-cbc -in БОЛЬШОЙ-ФАЙЛ.enc -out БОЛЬШОЙ-ФАЙЛ.enc -pass file:./key.bin

С помощью команды 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.

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

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: «Как пользоваться gpg: шифрование, расшифровка файлов и сообщений, подпись файлов и проверка подписи, управление ключами».

Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера

В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:

В CSR или пароле есть не латинские буквы и цифры. В CSR поддерживаются только латинские буквы и цифры – спецсимволы использовать запрещено. Это правило распространяется и на пароли для пары CSR/RSA: они не должны содержать спецсимволов.
Неверно указан код страны. Код страны должен быть двухбуквенным ISO 3166-1 кодом (к примеру, RU, US и т.д.). Он указывается в виде двух заглавных букв.
В управляющей строке не хватает символов. CSR-запрос должен начинаться с управляющей строки ——BEGIN CERTIFICATE REQUEST—— и заканчиваться управляющей строкой ——END CERTIFICATE REQUEST——. С каждой стороны этих строк должно быть по 5 дефисов.
В конце или начале строки CSR есть пробелы. Пробелы на концах строк в CSR не допускаются.
Длина ключа меньше 2048 бит. Длина ключа должна быть не менее 2048 бит.
В CRS-коде для сертификата для одного доменного имени есть SAN-имя. В CSR-коде для сертификата, предназначенного защитить одно доменное имя, не должно быть SAN (Subject Alternative Names). SAN-имена указываются для мультидоменных (UCC) сертификатов.
При перевыпуске или продлении сертификата изменилось поле Common Name. Это поле не должно меняться.

Читать также: Где посмотреть электронный сертификат на материнский капитал в личном кабинете госуслуг

Проблемы с датой и временем

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

Для исправления этой ошибки достаточно установить на устройстве актуальное время. После этого необходимо перезагрузить страницу или браузер.

Форматы ключей и сертификатов

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

Бинарный (DER) сертификат

Содержит сертификат X.509 в необработанном виде с использованием кодировки DER ASN.1.

ASCII (PEM) сертификат(ы)

Содержит сертификат DER в кодировке base64, в котором ——BEGIN CERTIFICATE—— используется в качестве заголовка, а ——END CERTIFICATE—— в качестве нижнего колонтитула. Обычно встречается только с одним сертификатом на файл, хотя некоторые программы допускают более одного сертификата в зависимости от контекста. Например, более старые версии веб-сервера Apache требуют, чтобы сертификат сервера был один в одном файле, а все промежуточные сертификаты — в другом.

Двоичный (DER) ключ

Содержит закрытый ключ в необработанном виде с использованием кодировки DER ASN.1. OpenSSL создаёт ключи в своём собственном традиционном (SSLeay) формате. Существует также альтернативный формат, называемый PKCS#8 (определённый в RFC 5208), но он не используется широко. OpenSSL может конвертировать в и из формата PKCS#8 с помощью команды pkcs8.

ASCII (PEM) ключ

Содержит ключ DER в кодировке base64, иногда с дополнительными метаданными (например, алгоритм, используемый для защиты паролем).

Сложный формат, предназначенный для транспортировки подписанных или зашифрованных данных, определённый в RFC 2315. Он обычно встречается с расширениями .p7b и .p7c и может при необходимости включать всю цепочку сертификатов. Этот формат поддерживается утилитой keytool Java.

PKCS#12 (PFX) ключ и сертификат(ы)

Сложный формат, который может хранить и защищать ключ сервера вместе со всей цепочкой сертификатов. Обычно встречается с расширениями .p12 и .pfx. Этот формат обычно используется в продуктах Microsoft, но также используется для клиентских сертификатов. В наши дни имя PFX используется как синоним для PKCS#12, хотя в прежние времена под PFX имелся ввиду другой формат (ранняя версия PKCS#12). Вряд ли вы встретите старую версию где-либо.

Код

QUIC — это новый экспериментальный протокол, который нужен для быстрого подключения к интернету. Основная задача протокола QUIC состоит в поддержке нескольких соединений. Вы можете отключить этот протокол в конфигурации вашего браузера.

Показываем как отключить QUIC на примере браузера Google Chrome:

Откройте браузер и введите команду chrome://flags/#enable-quic;
В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

Этот способ работает и в Windows и в Mac OS.

Обновить

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

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

Также нужно различать корневые сертификаты CA и сертификаты сайтов, которые вы добавили в доверенные — они также хранятся веб браузерами.

Корневые сертификаты Центров Сертификации (CA) в Linux

Консолидированный файл, включающий в себя все корневые сертификаты CA операционной системы, находится в файле /etc/ssl/certs/ca-certificates.crt. Этот файл может быть символической ссылкой на фактическое расположение сертификатов в файлах /etc/ssl/cert.pem или /etc/ca-certificates/extracted/tls-ca-bundle.pem.

Корневые CA сертификаты в виде отдельных файлов расположены в директории /etc/ssl/certs, в этой директории могут быть ссылки на фактическое расположение сертификатов, например, в /etc/ca-certificates/extracted/cadir/.

Для просмотра Subject всех корневых CA сертификатов в системе:

Эти сертификаты используются утилитоми curl, wget и другими. Веб-браузеры Chromium и Firefox используют свои собственные хранилища корневых CA сертификатов.

Чтобы узнать, где веб браузеры хранять корневые CA сертификаты в Linux, нам нужно познакомиться с NSS.

Mozilla Network Security Services (NSS)

Network Security Services (NSS) это набор библиотек, разработанных для поддержки кросс-платформенной разработки защищенных клиентских и серверных приложений. Приложения построенные с использование NSS могут использовать SSL v2 и v3, TLS, PKCS#5, PKCS#7, PKCS#11, PKCS#12, S/MIME, сертификаты X.509 v3 и другие стандарты обеспечения безопасности.

В отличие от OpenSSL, NSS использует файлы базы данных в качестве хранилища сертификатов.

NSS начинается с жёстко закодированного списка доверенных сертификатов CA внутри файла libnssckbi.so. Этот список можно просмотреть из любого приложения, использующего NSS, способного отображать (и манипулировать) хранилищем доверенных сертификатов, например, Chrome-совместимые или Firefox-совместимые браузеры.

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

В вашем дистрибутиве скорее всего уже установлен пакет NSS, в некоторых дистрибутивах он называется libnss3 (Debian и производные) в некоторых — nss (Arch Linux, Gentoo и производные).

Если вы хотите просматривать и изменять хранилища сертификатов NSS, то понадобиться утилита certutil. В Arch Linux эта утилита входит в пакет nss и, следовательно, предустановлена в Arch Linux. А в Debian и производные установка делается так:

sudo apt install libnss3-tools

Google Chrome / Chromium

Как уже было сказано, при работе на Linux, Google Chrome использует библиотеку Mozilla Network Security Services (NSS) для выполнения верификации сертификатов.

Корневые CA сертификаты, которые добавил пользователь, хранятся в файле ~/.pki/nssdb/cert9.db, их можно просмотреть командой:

certutil -L -d ~/.pki/nssdb

Используемые в Google Chrome / Chromium корневые CA сертификаты в Linux можно посмотреть следующим причудливым способом:

1. Найдите расположение файла libnssckbi.so (как было сказано в предыдущем разделе, в нём NSS хранит доверенные корневые сертификаты):

Примеры расположений этого файла:

/usr/lib/libnssckbi.so
/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so

2. Теперь выполните команду вида:

ln -s /ПУТЬ/ДО/libnssckbi.so ~/.pki/nssdb

ln -s /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so ~/.pki/nssdb

2. Затем запустите команду:

certutil -L -d sql:$HOME/.pki/nssdb/ -h ‘Builtin Object Token’

Вы увидите доверенные корневые сертификаты, которые использует Google Chrome в Linux.

Также вы можете просмотреть корневые CA сертификаты в настройках браузера:

Firefox

Поскольку Firefox принадлежит Mozilla, то этот веб браузер, конечно, также использует Mozilla Network Security Services (NSS).

Стандартными расположениями папок с базами данных NSS являются:

~/.pki/nssdb (на уровне пользователей)
/etc/pki/nssdb (на общесистемном уровне, может отсутствовать)

Firefox НЕ использует ни одно из этих стандартных расположений, база данных хранится в профиле пользователя, который имеет общий вид ~/.mozilla/firefox/СЛУЧАЙНЫЕ-БУКВЫ-ЦИФРЫ.default/cert9.db, например, ~/.mozilla/firefox/3k0r4loh.default/cert9.db.

Посмотреть корневые сертификаты CA которые использует Firefox в Linux можно следующей командой:

certutil -L -d ~/.mozilla/firefox/*.default/

У Firefox-esr это папка:

certutil -L -d ~/.mozilla/firefox/*.default-esr/

Thunderbird

Чтобы просмотреть, каким CA доверяет Thunderbird:

certutil -L -d ~/.thunderbird/*.default/

Чтобы найти все файлы cert9.db выполните команду:

find ~/ -name «cert9.db»

Корневые сертификаты Центров Сертификации (CA) в Windows

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

Читать также: Подарочный сертификат на отдых на море шаблон

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использует общесистемные доверенные корневые центры сертификации.

Opera

Как работают SSL сертификаты

приватный ключ
публичный ключ

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

Публичный и приватный ключ генерируются вмести и криптографически связаны.

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

Любой может сгенерировать пару ключей, поэтому возникает проблема идентификации — как проверить, что публичный ключ выпущен определённым лицом?

Это можно было бы сделать например так: владелец сайт mysite.org генерирует пару публичный-приватный ключ и просит третью сторону подписать его публичный ключ. В результате публичный ключ распространяется с цифровой подписью, которую можно проверить публичным ключом третьей стороны. На самом деле, всё именно так и происходит, а подписанный публичный ключ, вместе с дополнительной информацией (например, название домена, для которого он подписан) упаковываются в сертификат.

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

В результате процедура создания сертификата выглядит так:

Владельцем сайта генерируется пара приватный и публичный ключ.
Публичный ключ вместе с другой информацией для подписи (например, название доменного имени) упаковывается в файл в специальном формате. Он называется — Certificate Signing Request (CSR), то есть «запроса на подпись сертификата».
Данный запрос на подпись (CSR) отправляется в Центр Сертификации (CA), который, используя свой приватный корневой ключ, создаёт подпись для этих данных и всё это упаковывается в другой специальный файл, называемый сертификат.

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

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

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

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

Как создать сертификаты SSL (TLS) для сайтов

Создайте корневой приватный ключ

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

Генерация приватного ключа RSA используя параметры по умолчанию (ключ будет сохранён в файл с именем rootCA.key):

openssl genpkey -algorithm RSA -out rootCA.key

Опция -out указывает на имя файла для сохранения, без этой опции файл будет выведен в стандартный вывод (на экран). Имя выходного файла не должно совпадать с именем входного файла.

Для безопасности ключа его следует защитить паролем. Генерация приватного ключа RSA используя 128-битное AES шифрование (-aes-128-cbc) и парольную фразу «hello» (-pass pass:hello):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pass pass:hello

Конечно, опцию -pass pass:hello можно не указывать, тогда вам будет предложено ввести пароль во время генерации ключа.

Список поддерживаемых симметричных алгоритмов шифрования приватного ключа можно узнать в документации (раздел SUPPORTED CIPHERS):

Если для генерируемого ключа не указано количество бит, то по умолчанию используется 2048, вы можете указать другое количество бит с помощью команды вида (будет создан 4096-битный ключ):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pkeyopt rsa_keygen_bits:4096

Создание самоподписанного корневого сертификата

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt

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

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

Чтобы создать приватный ключ сертификата

openssl genpkey -algorithm RSA -out mydomain.com.key

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

Создание файла с запросом на подпись сертификата (csr)

Получив закрытый ключ, вы можете приступить к созданию запроса на подпись сертификата — Certificate Signing Request (CSR). Это официальный запрос к CA о подписании сертификата, который содержит открытый ключ объекта, запрашивающего сертификат, и некоторую информацию об объекте. Все эти данные будут частью сертификата. CSR всегда подписывается закрытым ключом, соответствующим открытому ключу, который он несёт.

Создание CSR обычно представляет собой интерактивный процесс, в ходе которого вы будете предоставлять элементы отличительного имени сертификата (вводить информацию о стране, городе, организации, email и т.д.). Внимательно прочитайте инструкции, предоставленные инструментом openssl; если вы хотите, чтобы поле было пустым, вы должны ввести одну точку (.) в строке, а не просто нажать «Enter». Если вы сделаете последнее, OpenSSL заполнит соответствующее поле CSR значением по умолчанию. (Такое поведение не имеет никакого смысла при использовании с конфигурацией OpenSSL по умолчанию, что и делают практически все. Это имеет смысл, когда вы осознаете, что можете изменить значения по умолчанию, либо изменив конфигурацию OpenSSL, либо предоставив свои собственные конфигурации в файлах).

В запросе на подпись сертификата вы указываете информацию для сертификата, который хотите сгенерировать. Этот запрос будет обработан владельцем корневого ключа (в данном случае вы его создали ранее) для генерации сертификата.

Я опишу здесь два способа:

Если вы создадите CSR таким способом, openssl задаст вам вопросы о сертификате, который необходимо сгенерировать, например, сведения об организации и Common Name (CN), которое является веб-адресом, для которого вы создаёте сертификат, например, mydomain.com.

openssl req -new -key mydomain.com.key -out mydomain.com.csr

Метод Б (в одну команду без запросов)

Этот метод генерирует тот же результат, что и метод A, но он подходит для использования в вашей автоматизации.

openssl req -new -sha256 -key mydomain.com.key -subj «/C=US/ST=CA/O=MyOrg, Inc./CN=mydomain.com» -out mydomain.com.csr

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

Проверьте содержание CSR

После создания CSR используйте его, чтобы подписать собственный сертификат и/или отправить его в общедоступный центр сертификации и попросить его подписать сертификат. Оба подхода описаны в следующих разделах. Но прежде чем сделать это, неплохо бы ещё раз проверить правильность CSR. Это делается так:

openssl req -in mydomain.com.csr -noout -text

Создайте сертификат, используя csr для mydomain.com, корневые ключ и сертификат CA.

Если вы устанавливаете сервер TLS для своего собственного использования, вы, вероятно, не хотите идти в ЦС для покупки публично доверенного сертификата. Намного проще использовать сертификат, подписанный вашим собственным CA. Если вы являетесь пользователем Firefox, при первом посещении веб-сайта вы можете создать исключение для сертификата, после которого сайт будет защищён так, как если бы он был защищён общедоступным сертификатом.

Если у вас уже есть CSR, создайте сертификат, используя следующую команду:

openssl x509 -req -in mydomain.com.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out mydomain.com.crt -days 500 -sha256

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

rootCA.key — приватный ключ Центра Сертификации, должен храниться в секрете в CA
rootCA.crt — публичный корневой сертификат Центра Сертификации — должен быть установлен на всех пользовательских устройствах
mydomain.com.key — приватный ключ веб-сайта, должен храниться в секрете на сервере. Указывает в конфигурации виртуального хоста при настройке веб-сервера
mydomain.com.csr — запрос на подпись сертификата, после создания сертификата этот файл не нужен, его можно удалить
mydomain.com.crt — сертификат сайта. Указывает в конфигурации виртуального хоста при настройке веб-сервера, не является секретным.

Обновление 2

PHP Warning: stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Создан 09 сен.

26 золотых значков82 серебряных знака93 бронзовых знака

25 Авг ’15 в 18:19

Вам нужно будет найти сертификат CA, сгенерированный на сервере, подписавшем сертификат SSL, и скопировать его на этот сервер. Если вы используете самозаверяющие сертификаты, вам необходимо добавить сертификат CA, который использовался для подписи SSL-сертификата удаленного хоста, в доверенное хранилище на сервере, с которого вы подключаетесь, ИЛИ используйте контексты потока, чтобы использовать этот сертификат для каждый индивидуальный запрос. Добавление его в доверенные сертификаты — самое простое решение. Просто добавьте содержимое сертификата CA удаленного хоста в конец загруженного вами файла cacert.pem.

Читать также: Как получить новый сертификат на утилизацию

fsockopen не поддерживает контексты потоков, поэтому используйте вместо них stream_socket_client. Он возвращает ресурс, который можно использовать со всеми командами, которые могут использовать ресурсы fsockopen.

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

изменён 25 мая в 18:02

Бег 36,4 км15 золотых значков82 серебряных знака113 бронзовых знаков

3 сентября ’15 в 2:57

10 серебряных значков14 бронзовых знаков

У меня возникла аналогичная проблема при работе с Ubuntu 16.04 с помощью Docker. В моем случае это была проблема с Composer, но сообщение об ошибке (и, следовательно, проблема) было таким же.

Из-за минималистичного базового образа, ориентированного на Docker, мне не хватало ca-certificatesapt-get install ca-certificates

12 июля ’16 в 14:37

Проблема в новой версии PHP в macOS Sierra

stream_context_set_option($ctx, ‘ssl’, ‘verify_peer’, false);

5 июня ’17 в 9:20

13 ноября ’16 в 18:20

# My root ca-trust folder was here. I coped the .crt file to this location
# and renamed it to a .pem
/etc/pki/ca-trust/source/anchors/self-signed-cert.pem

# Then run this command and it will regenerate the certs for you and
# include your self signed cert file.
update-ca-trust

Затем некоторые из моих вызовов api начали работать, поскольку моему сертификату теперь доверяли. Также, если ваш ca-trust обновляется через yum или что-то в этом роде, это восстановит ваши корневые сертификаты и по-прежнему будет включать ваш самоподписанный сертификат. man update-ca-trustчтобы узнать, что делать и как это делать.

8 июля ’16 в 17:21

1 золотой значок16 серебряных значков23 бронзовых знака

Во-первых, убедитесь, что ваше антивирусное программное обеспечение не блокирует SSL2.
Потому что долго не мог решить проблему и помогло только отключение антивируса

26 ноября ’18 в 17:12

Вы упомянули, что сертификат самоподписан (вами)? Тогда у вас есть два варианта:

добавьте сертификат в хранилище доверенных сертификатов (загрузка cacert.pemс веб-сайта cURL ничего не даст, так как он самоподписанный)
не утруждайте себя проверкой сертификата: вы ведь доверяете себе?

allow_self_signedесли вы импортируете сертификат в хранилище доверенных сертификатов, или установите verify_peerзначение false, чтобы пропустить проверку.

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

7 сентября ’15 в 13:52

11 серебряных значков26 бронзовых знаков

Если вы используете macOS sierra, есть обновление версии PHP. вам необходимо добавить файл Entrust.net Certificate Authority (2048) в код PHP. подробнее проверьте принятый ответ здесь Push-уведомление в PHP с использованием файла PEM

Создан 23 мая ’17 в 15: 262017-05-23 15:26

28 марта ’17 в 5:15

1 золотой значок29 серебряных значков47 бронзовых знаков

Вы пробовали использовать stream_context_set_option()

$context = stream_context_create();
$result = stream_context_set_option($context, ‘ssl’, ‘local_cert’, ‘/etc/ssl/certs/cacert.pem’);
$fp = fsockopen($host, $port, $errno, $errstr, 20, $context);

Кроме того, попробуйте file_get_contents()получить файл pem, чтобы убедиться, что у вас есть разрешения на доступ к нему, и убедитесь, что имя хоста соответствует сертификату.

27 августа ’15 в 21:42

1 золотой значок9 серебряных значков22 бронзовых знака

Инструкция по использованию и аудит безопасности

Знаете ли вы, что один единственный корневой сертификат хакера, установленный в вашу систему, фактически лишает её защиты с помощью шифрования SSL (TLS)? Знаете ли вы, что на самом деле для передачи основных данных браузеры не используют ассиметричное шифрование (с помощью сертификатов), а используют симметричное (парольная фраза)? Задумывались ли вы, можете ли Удостоверяющий Центр, выдавший SSL сертификат, расшифровать при желании передаваемый на сайт трафик? Почему VNC сессия, защищённая самодельным сертификатом, считается надёжной, а подключение к сайту, использующего такой же сертификат, нет? Почему для сайтов не подходят самодельные сертификаты? Знаете ли вы, что в вашей системе уже установлены сотни корневых сертификатов различных Центров Сертификации которым безоговорочно доверяют веб браузеры и другие приложения?

В этой статье мы разберёмся, как работает SSL (TLS) шифрование, как пользоваться утилитами OpenSSL, как создавать свои собственные ключи и Центры Сертификации, как подписывать сертификаты для сайтов, как просмотреть детальную информацию о сертификате и ключе, как конвертировать сертификаты в различные форматы и как проверить различные аспекты безопасности SSL (TLS), как проверить, какие сертификаты установлены в качестве доверенных корневых, как добавить новый доверенный сертификат или удалить сертификат из доверенных..

Проверка настройки HTTPS

Команда s_client выполняет функции SSL/TLS клиента для подключения к удалённому хосту с использованием SSL/TLS. Данная программа позволяет подключаться с различными настройками SSL/TLS — выбирать используемые шифры, версию рукопожатия, использовать определённые протоколы, тестировать повторное использование сессий. При этом программа показывает все переданные и полученные во время SSL/TLS подключения данные. Благодаря этому возможна доскональная проверка настроек сервера SSL/TLS, тестирование списка отзыва сертификатов и даже проверка на уязвимости.

Для подключения к удалённому хосту укажите адрес домена и порт (обычно это 443) с опцией -connect:

1. верификацию и цепочку сертификатов

2. сертификат сайта

3. данные текущей сессии — SSL/TLS (ассиметричное шифрование) используются для обмена ключом для симметричного шифрования, поскольку ассиметричное слишком «затратное». И фактический шифрование данных будет выполняться «паролем» (ключами сессии, а не сертификатом). Эти ключи меняются при каждой новой сессии.

То есть, компрометация приватного ключа сервера ≠ расшифровка трафика. Поскольку необходимо знать все ключи сессии. Раньше, зная приватный ключ сервера, можно было расшифровать SSL трафик — сначала расшифровывались ключи сессии, а затем они использовались для расшифровки данных. Но теперь используется Perfect Forward Secrecy (которая применяет Diffie-Hellman key exchange (DH)), что привело к тому, что третья сторона, даже зная приватный ключ RSA (приватный ключ сервера), не сможет расшифровать TLS трафик.

В предыдущем выводе вы могли обратить внимание, что он содержит сертификат сайта. На самом деле, сервер обычно отправляет цепочку сертификатов — сертификат сайта и все сертификаты промежуточных Центров Сертификации. Чтобы увидеть все сертификаты, которые отправил сервер, используйте опцию -showcerts:

Для yandex.ru будет выведено 3 сертификата: 1 сертификат сайта и 2 промежуточных.

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

openssl s_client -showcerts -connect yandex.ru:443 </dev/null

Чтобы сохранить сертификат сайта в файл используйте следующую команду (дважды замените w-e-b.site на интересующий вас домен):

Если вы хотите сохранить всю присылаемую цепочку сертификатов, то сделайте так (дважды замените w-e-b.site на интересующий вас домен):

Проверка TLS/SSL веб-сайта с указанием Центра Сертификации

Если веб-сайт использует самостоятельно созданный сертификат, который не подписан Глобальными Центрами Сертификации, то с помощью опции -CAfile можно указать сертификат того CA, который вы использовали для подписи:

openssl s_client -connect w-e-b.site:443 -CAfile /etc/ssl/CA.crt

Это подходит, например, для тестирования сгенерированных сертификатов на локальном сервере без добавления самодельного CA в корневые Центры Сертификации ОС.

Тестирование протоколов, которые обновляются до SSL

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

Поддерживаются в частности следующие протоколы: smtp, pop3, imap, ftp и xmpp.

Во время установки соединения SSL/TLS «под капотом» выполняется много работы. Если у нас есть какие-то проблемы или нам нужна подробная информация об инициализации SSL/TLS, мы можем использовать опцию -tlsextdebug, как показано ниже.

openssl s_client -connect w-e-b.site:443 -tlsextdebug

Поддержка протокола тестирования

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

Protocol : TLSv1.3

Если вам нужно протестировать поддержку определённых версий протокола, у вас есть два варианта. Вы можете явно выбрать один протокол для тестирования, указав один из ключей —ssl3, -tls1, -tls1_1, -tls1_2 или -tls1_3. Кроме того, вы можете выбрать протоколы, которые вы не хотите тестировать, используя один или несколько из следующих параметров: -no_ssl3, -no_tls1, -no_tls1_1, -no_tls1_2 или -no_tls1_3.

Примечание: не все версии OpenSSL поддерживают все версии протокола. Например, более старые версии OpenSSL не будут поддерживать TLS 1.2 и TLS 1.3, а более новые версии могут не поддерживать более старые протоколы, такие как SSL 2 и SSL 3. К примеру, при попытке использовать опцию -ssl3 на современных версиях OpenSSL возникает ошибка:

s_client: Option unknown option -ssl3

Интерактивные запросы с s_client

Как вы можете увидеть, подключение с помощью s_client не прекращается до истечении таймаута — программа и сервер ожидают ввод данных.

К примеру, выполним подключение:

Получение HTML кода страницы (пример использования метода GET с запросом адреса страницы):

При использовании s_client всегда возникает ошибка «HTTP/1. 1 400 Bad Request»

Как можно понять из текста ошибки — сервер получил плохой запрос. Причины могут быть разными:

Например, подключимся к серверу:

Попробуем ввести первый заголовок и нажмём Enter:

Сразу после этого возникнет ошибка — ваш браузер отправил запрос, который этот сервер не может понять:

В данном случае необходимо использовать опцию -crlf, она переводит line feed от терминала в CR+LF, как этого требуют некоторые серверы:

openssl s_client -connect w-e-b.site:443 -crlf

Для того, чтобы s_client перестал ожидать ввод и отправил данные на сервер, нажмите Enter дважды.