Как создать самозаверяющий сертификат с openssl?

Я добавляю поддержку https для встроенного Linux-устройства. Я попытался создать самозаверяющий сертификат с этими шагами:

openssl req -new > cert.csr openssl rsa -in privkey.pem -out key.pem openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001 cat key.pem>>cert.pem 

Это работает, но я получаю некоторые ошибки, например, с помощью google chrome:

Возможно, это не тот сайт, который вы ищете!
Сертификату безопасности сайта не доверяют!

Я что-то упускаю? Это правильный способ создания самозаверяющего сертификата?

Вы можете сделать это в одной команде:

 openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 

Вы также можете добавить -nodes если вы не хотите защищать свой закрытый ключ парольной фразой, иначе он предложит вам пароль «как минимум 4 символа». Параметр days (365) можно заменить любым числом, чтобы повлиять на дату истечения срока действия. Затем он предложит вам такие вещи, как «Название страны», но вы можете просто нажать «Ввод» и принять значения по умолчанию.

Добавьте -subj '/CN=localhost' чтобы -subj '/CN=localhost' вопросы о содержимом сертификата (замените localhost на нужный домен)

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

Я что-то упускаю? Это правильный способ создания самозаверяющего сертификата?

Его легко создать самостоятельно подписанный сертификат. Вы просто используете команду openssl req . Может быть сложно создать тот, который может потребляться самым большим выбором клиентов, например браузерами и инструментами командной строки.

Это сложно, потому что у браузеров есть свой набор требований, и они более ограничительны, чем IETF. Требования, используемые браузерами, документируются на форумах CA / Browser (см. Ссылки ниже). Ограничения возникают в двух ключевых областях: (1) доверительные привязки и (2) имена DNS.

Современные браузеры (например, warez, которые мы используем в 2014/2015 году) хотим получить сертификат, который привязывается к доверенному ядру, и они хотят, чтобы имена DNS были представлены в сертификате определенным образом. И браузеры активно двигаются против самоподписанных серверных сертификатов

Некоторые браузеры не позволяют легко импортировать сертификат самоподписанного сервера. Фактически, вы не можете работать с некоторыми браузерами, такими как браузер Android. Таким образом, полное решение – стать вашим собственным авторитетом.

Если вы не становитесь собственными полномочиями, вы должны получить имена DNS, чтобы дать сертификату наибольшие шансы на успех. Но я бы посоветовал вам стать вашим собственным авторитетом. Его легко стать вашим собственным авторитетом, и он будет подкреплять все доверительные проблемы (кому лучше доверять, чем вы сами).


Возможно, это не тот сайт, который вы ищете!
Сертификату безопасности сайта не доверяют!

Это связано с тем, что браузеры используют предопределенный список привязок доверия для проверки сертификатов сервера. Самоподписанный сертификат не привязывается к доверенному якорю.

Лучший способ избежать этого:

  1. Создайте свой собственный авторитет (т. Е. Станьте ЦС)
  2. Создайте запрос подписи сертификата (CSR) для сервера
  3. Подпишите CSR сервера с помощью ключа CA
  4. Установка сертификата сервера на сервере
  5. Установка сертификата CA на клиенте

Шаг 1 – Создайте свой собственный авторитет, просто создайте самоподписанный сертификат с CA: true и правильное использование ключа. Это означает, что Субъект и Эмитент являются одним и тем же объектом, для CA установлено значение true в Basic Constraints (оно также должно быть отмечено как критическое), использование ключа – keyCertSign и crlSign (если вы используете CRL) и идентификатор ключевого слова (SKI) ) совпадает с идентификатором ключа управления (AKI).

Чтобы стать вашим собственным центром сертификации, см. Раздел «Как вы подписываете запрос на подпись сертификата в своем сертификационном центре? на переполнение стека. Затем импортируйте свой ЦС в хранилище доверия, используемое браузером.

Шаги 2 – 4 примерно соответствуют тому, что вы делаете сейчас для публичного сервера, когда вы заручитесь услугами центра сертификации, такого как Startcom или CAcert . Шаги 1 и 5 позволяют вам избежать полномочий третьей стороны и действовать как ваша собственная власть (кому лучше доверять, чем вы сами).

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

Проблема браузеров (и других аналогичных пользовательских агентов), не доверяющих самоподписанным сертификатам, будет большой проблемой в Internet of Things (IoT). Например, что произойдет, когда вы подключитесь к своему термостату или холодильнику, чтобы запрограммировать его? Ответ заключается в том, что ничего хорошего в отношении пользовательского опыта.

Рабочая группа W3C WebAppSec начинает рассматривать эту проблему. См., Например, Предложение: Маркировка HTTP как небезопасная .


Как создать самозаверяющий сертификат с openssl?

Команды ниже и файл конфигурации создают самоподписанный сертификат (он также показывает, как создать запрос подписи). Они отличаются от других ответов в одном отношении: имена DNS, используемые для самоподписанного сертификата, находятся в альтернативном имени субъекта (SAN) , а не в Common Name (CN) .

Имена DNS помещаются в SAN через файл конфигурации с линией subjectAltName = @alternate_names (нет возможности сделать это через командную строку). Затем в файле конфигурации есть раздел alternate_names (вы должны настроить его в соответствии с вашим вкусом):

 [ alternate_names ] DNS.1 = example.com DNS.2 = www.example.com DNS.3 = mail.example.com DNS.4 = ftp.example.com # Add these if you need them. But usually you don't want them or # need them in production. You may need them for development. # DNS.5 = localhost # DNS.6 = localhost.localdomain # DNS.7 = 127.0.0.1 # IPv6 localhost # DNS.8 = ::1 

Важно указать DNS-имя в SAN, а не CN, потому что и IETF, и CA / Browser Forums определяют эту практику. Они также указывают, что имена DNS в CN устарели (но не запрещены). Если вы поместите DNS-имя в CN, оно должно быть включено в SAN в соответствии с политиками CA / B. Поэтому вы не можете избежать использования альтернативного имени темы.

Если вы не вводите DNS-имена в SAN, сертификат не будет проверяться в браузере и других пользовательских агентах, которые следуют рекомендациям CA / Browser Forum.

Связано: браузеры следуют политике CA / Browser Forum; а не политики IETF. Это одна из причин того, что сертификат, созданный с помощью OpenSSL (который обычно следует за IETF), иногда не проверяется под браузером (браузеры следуют за CA / B). Они разные стандарты, у них разные политики выдачи и разные требования к валидации.


Создайте самоподписанный сертификат (обратите внимание на добавление опции -x509 ):

 openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \ -keyout example-com.key.pem -days 365 -out example-com.cert.pem 

Создайте запрос подписи (обратите внимание на отсутствие опции -x509 ):

 openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \ -keyout example-com.key.pem -days 365 -out example-com.req.pem 

Распечатайте самоподписанный сертификат :

 openssl x509 -in example-com.cert.pem -text -noout 

Распечатайте запрос подписи :

 openssl req -in example-com.req.pem -text -noout 

Файл конфигурации (передается через опцию -config )

 [ req ] default_bits = 2048 default_keyfile = server-key.pem distinguished_name = subject req_extensions = req_ext x509_extensions = x509_ext string_mask = utf8only # The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description). # Its sort of a mashup. For example, RFC 4514 does not provide emailAddress. [ subject ] countryName = Country Name (2 letter code) countryName_default = US stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = NY localityName = Locality Name (eg, city) localityName_default = New York organizationName = Organization Name (eg, company) organizationName_default = Example, LLC # Use a friendly name here because its presented to the user. The server's DNS # names are placed in Subject Alternate Names. Plus, DNS names here is deprecated # by both IETF and CA/Browser Forums. If you place a DNS name here, then you # must include the DNS name in the SAN too (otherwise, Chrome and others that # strictly follow the CA/Browser Baseline Requirements will fail). commonName = Common Name (eg server FQDN or YOUR name) commonName_default = Example Company emailAddress = Email Address emailAddress_default = [email protected] # Section x509_ext is used when generating a self-signed certificate. Ie, openssl req -x509 ... [ x509_ext ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer # You only need digitalSignature below. *If* you don't allow # RSA Key transport (ie, you use ephemeral cipher suites), then # omit keyEncipherment because that's key transport. basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" # RFC 5280, Section 4.2.1.12 makes EKU optional # CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused # In either case, you probably only need serverAuth. # extendedKeyUsage = serverAuth, clientAuth # Section req_ext is used when generating a certificate signing request. Ie, openssl req ... [ req_ext ] subjectKeyIdentifier = hash basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" # RFC 5280, Section 4.2.1.12 makes EKU optional # CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused # In either case, you probably only need serverAuth. # extendedKeyUsage = serverAuth, clientAuth [ alternate_names ] DNS.1 = example.com DNS.2 = www.example.com DNS.3 = mail.example.com DNS.4 = ftp.example.com # Add these if you need them. But usually you don't want them or # need them in production. You may need them for development. # DNS.5 = localhost # DNS.6 = localhost.localdomain # DNS.7 = 127.0.0.1 # IPv6 localhost # DNS.8 = ::1 

Для Chrome вам может потребоваться следующее. В противном случае Chrome может пожаловаться на то, что общее имя недействительно ( ERR_CERT_COMMON_NAME_INVALID ) . Я не уверен, что отношения между IP-адресом в SAN и CN в этом случае.

 # IPv4 localhost # IP.1 = 127.0.0.1 # IPv6 localhost # IP.2 = ::1 

Существуют и другие правила, касающиеся обработки имен DNS в сертификатах X.509 / PKIX. Обратитесь к этим документам за правилами:

  • RFC 5280, Internet X.509 Сертификат инфраструктуры открытых ключей и список отзыва сертификатов (CRL)
  • RFC 6125, представление и верификация идентификатора службы на основе доменного приложения в инфраструктуре открытого ключа Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS)
  • RFC 6797, Приложение A, Строгая транспортная безопасность HTTP (HSTS)
  • RFC 7469, расширение открытого ключа для HTTP
  • Требования к базовому стандарту CA / Browser Forum
  • Расширенные рекомендации по CA / Browser Forum

RFC 6797 и RFC 7469 перечислены, потому что они являются более ограничительными, чем другие документы RFC и CA / B. 6797 и 7469 RFC также не разрешают IP-адрес.

Вот варианты, описанные в ответе @ diegows , более подробно описанные в документации :

 openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX 
 req 

PKCS № 10 запрос сертификата и утилита создания сертификатов.

 -x509 

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

 -newkey arg 

этот параметр создает новый запрос сертификата и новый закрытый ключ. Аргумент принимает одну из нескольких форм. rsa: nbits , где nbits – это количество бит, генерирует nbits ключа RSA в размере.

 -keyout filename 

это дает имя файла для записи вновь созданного закрытого ключа.

 -out filename 

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

 -days n 

когда используется опция -x509 , это указывает количество дней, на которые удостоверяется сертификат. Значение по умолчанию – 30 дней.

 -nodes 

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

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

Следующая команда обслуживает все ваши потребности:

 openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650 

Он создает сертификат для домена example.com который

  • относительно сильные (по состоянию на 2018 год) и
  • действителен в течение 3650 дней (~ 10 лет).

Он создает следующие файлы:

  • Закрытый ключ: example.key
  • Сертификат: example.crt

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

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

В будущем вы можете использовать более 4096 бит для ключа RSA и алгоритм хеширования, более сильный, чем sha256 , но с 2018 года это нормальные значения. Они достаточно прочны, поддерживаются всеми современными браузерами.

Примечание. Теоретически вы можете оставить параметр -nodes (что означает «отсутствие шифрования DES»), и в этом случае example.key будет зашифрован паролем. Однако это почти никогда не бывает полезно для установки сервера, поскольку вам придется либо хранить пароль на сервере, либо вам придется вводить его вручную при каждой перезагрузке.

Я не могу комментировать, так что это будет отдельным ответом. Я нашел несколько проблем с принятым однострочным ответом:

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

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

 openssl genrsa -out server.key 2048 openssl rsa -in server.key -out server.key openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost' openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt 

Замените «localhost» на любой домен, который вам нужен. Вам нужно будет запускать первые две команды один за другим, так как openssl будет запрашивать кодовую фразу.

Чтобы объединить два файла в файл .pem:

 cat server.crt server.key > cert.pem 

Я бы рекомендовал добавить параметр -sha256 , чтобы использовать алгоритм hashа SHA-2, потому что основные браузеры рассматривают, чтобы показать «сертификаты SHA-1» как небезопасные.

Одна и та же командная строка из принятого ответа – @diegows с добавлением -sha256

openssl req -x509 -sha256 -newkey rsa: 2048 -keyout key.pem -out cert.pem -days XXX

Подробнее в блоге безопасности Google .

Обновление до 2018 года. Как отмечалось в комментариях, использование SHA-2 не добавляет никакой безопасности для самоподписанного сертификата. Но я по-прежнему рекомендую использовать его как хорошую привычку не использовать устаревшие / небезопасные криптографические hash-функции. Полное объяснение доступно в: https://security.stackexchange.com/questions/91913/why-is-it-fine-for-certificates-above-the-end-entity-certificate-to-be-sha1-base

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

Самый быстрый способ запустить снова – это короткий автономный файл conf:

  1. Создайте конфигурационный файл OpenSSL (пример: req.cnf )

     [req] distinguished_name = req_distinguished_name x509_extensions = v3_req prompt = no [req_distinguished_name] C = US ST = VA L = SomeCity O = MyCompany OU = MyDivision CN = www.company.com [v3_req] keyUsage = critical, digitalSignature, keyAgreement extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = www.company.com DNS.2 = company.com DNS.3 = company.net 
  2. Создайте сертификат, ссылающийся на этот файл конфигурации

     openssl req -x509 -nodes -days 730 -newkey rsa:2048 \ -keyout cert.key -out cert.pem -config req.cnf -sha256 

Пример конфигурации из https://support.citrix.com/article/CTX135602

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

Этот скрипт принимает имя домена (example.com) и генерирует SAN для * .example.com и example.com в том же сертификате. Прокомментированы следующие разделы. Назовите сценарий (например, generate-ssl.sh ) и дайте ему исполняемые разрешения. Файлы будут записаны в тот же каталог, что и скрипт.

Для Chrome 58 требуется, чтобы SAN устанавливался в самозаверяющих сертификатах.

 #!/usr/bin/env bash # Set the TLD domain we want to use BASE_DOMAIN="example.com" # Days for the cert to live DAYS=1095 # A blank passphrase PASSPHRASE="" # Generated configuration file CONFIG_FILE="config.txt" cat > $CONFIG_FILE <<-EOF [req] default_bits = 2048 prompt = no default_md = sha256 x509_extensions = v3_req distinguished_name = dn [dn] C = CA ST = BC L = Vancouver O = Example Corp OU = Testing Domain emailAddress = [email protected]$BASE_DOMAIN CN = $BASE_DOMAIN [v3_req] subjectAltName = @alt_names [alt_names] DNS.1 = *.$BASE_DOMAIN DNS.2 = $BASE_DOMAIN EOF # The file name can be anything FILE_NAME="$BASE_DOMAIN" # Remove previous keys echo "Removing existing certs like $FILE_NAME.*" chmod 770 $FILE_NAME.* rm $FILE_NAME.* echo "Generating certs for $BASE_DOMAIN" # Generate our Private Key, CSR and Certificate # Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017 openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE" # OPTIONAL - write an info to see the details of the generated crt openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info" # Protect the key chmod 400 "$FILE_NAME.key" 

Этот скрипт также записывает информационный файл, чтобы вы могли проверить новый сертификат и проверить правильность установки SAN.

  ... 28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4: da:3d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DNS:*.example.com, DNS:example.com Signature Algorithm: sha256WithRSAEncryption 3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc: ... 

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

  ServerName example.com ServerAlias www.example.com DocumentRoot /var/www/htdocs SSLEngine on SSLCertificateFile path/to/your/example.com.crt SSLCertificateKeyFile path/to/your/example.com.key  

Не забудьте перезапустить сервер Apache (или Nginx или IIS), чтобы новый сертификат вступил в силу.

2017 Один вкладыш:

 openssl req \ -newkey rsa:2048 \ -x509 \ -nodes \ -keyout server.pem \ -new \ -out server.pem \ -subj /CN=localhost \ -reqexts SAN \ -extensions SAN \ -config <(cat /System/Library/OpenSSL/openssl.cnf \ <(printf '[SAN]\nsubjectAltName=DNS:localhost')) \ -sha256 \ -days 3650 

Это также работает в Chrome 57, так как он предоставляет SAN без наличия другого файла конфигурации. Взято из ответа здесь . Это создает один файл .pem, который содержит как закрытый ключ, так и сертификат. Вы можете переместить их, чтобы отделить файлы .pem, если это необходимо.

У вас правильная процедура. Синтаксис команды приведен ниже.

 openssl req -new -key {private key file} -out {output file} 

Однако предупреждения отображаются, поскольку браузер не смог проверить идентификацию, подтвердив сертификат сертификатом с известным центром сертификации (CA).

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

  1. Создайте закрытый ключ
  2. Используйте этот закрытый ключ для создания файла CSR
  3. Отправить CSR в CA (Verisign или другие и т. Д.)
  4. Установите полученный сертификат из CA на веб-сервере
  5. Добавьте другие сертификаты в цепочку аутентификации в зависимости от типа сертификата

У меня есть более подробная информация об этом в сообщении на странице https://bigthinkingapplied.com/secure-the-connection-installing-certificates-on-3-common-web-servers/

Один вкладыш FTW. Мне нравится держать его простым. Почему бы не использовать одну команду, содержащую ВСЕ необходимые аргументы? Вот как мне это нравится: это создает сертификат x509, и это ключ PEM:

 openssl req -x509 \ -nodes -days 365 -newkey rsa:4096 \ -keyout self.key.pem \ -out self-x509.crt \ -subj "/C=US/ST=WA/L=Seattle/CN=example.com/[email protected]" 

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

>> больше здесь <<

Создание ключей

Я использую /etc/mysql для хранения сертификатов, потому что /etc/apparmor.d/usr.sbin.mysqld содержит /etc/mysql/*.pem r .

 sudo su - cd /etc/mysql openssl genrsa -out ca-key.pem 2048; openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem; openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem; openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem; openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem; openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem; 

Добавить конфигурацию

/etc/mysql/my.cnf

 [client] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/client-cert.pem ssl-key=/etc/mysql/client-key.pem [mysqld] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem и [client] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/client-cert.pem ssl-key=/etc/mysql/client-key.pem [mysqld] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem и [client] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/client-cert.pem ssl-key=/etc/mysql/client-key.pem [mysqld] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem и [client] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/client-cert.pem ssl-key=/etc/mysql/client-key.pem [mysqld] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem и [client] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/client-cert.pem ssl-key=/etc/mysql/client-key.pem [mysqld] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem и [client] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/client-cert.pem ssl-key=/etc/mysql/client-key.pem [mysqld] ssl-ca=/etc/mysql/ca-cert.pem ssl-cert=/etc/mysql/server-cert.pem ssl-key=/etc/mysql/server-key.pem 

В моей настройке сервер ubuntu зарегистрировался на: /var/log/mysql/error.log

Последующие примечания:

  • SSL error: Unable to get certificate from '...'

    Mysql может быть лишен доступа для чтения к вашему файлу cert, если он не находится в конфигурации apparmors . Как упоминалось в предыдущих шагах ^, сохраните все наши сертификаты как .pem файлы в каталоге /etc/mysql/ который по умолчанию одобрен apparmor (или измените ваш apparmor / SELinux, чтобы разрешить доступ туда, где вы их сохранили).

  • SSL error: Unable to get private key

    Ваша версия сервера mysql может не поддерживать формат rsa:2048 по умолчанию.

    Скрытая сгенерированная rsa:2048 до простой rsa с:

     openssl rsa -in server-key.pem -out server-key.pem openssl rsa -in client-key.pem -out client-key.pem 
  • Проверьте, поддерживает ли локальный сервер ssl :

     mysql -u root -p mysql> show variables like "%ssl%"; +---------------+----------------------------+ | Variable_name | Value | +---------------+----------------------------+ | have_openssl | YES | | have_ssl | YES | | ssl_ca | /etc/mysql/ca-cert.pem | | ssl_capath | | | ssl_cert | /etc/mysql/server-cert.pem | | ssl_cipher | | | ssl_key | /etc/mysql/server-key.pem | +---------------+----------------------------+ 
  • Проверка соединения с db зашифрована ssl :

    Проверка соединения

    При входе в экземпляр MySQL вы можете отправить запрос:

     show status like 'Ssl_cipher'; 

    Если ваше соединение не зашифровано, результат будет пустым:

     mysql> show status like 'Ssl_cipher'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Ssl_cipher | | +---------------+-------+ 1 row in set (0.00 sec) 

    В противном случае он будет показывать строку с ненулевой длиной для используемого cypher:

     mysql> show status like 'Ssl_cipher'; +---------------+--------------------+ | Variable_name | Value | +---------------+--------------------+ | Ssl_cipher | DHE-RSA-AES256-SHA | +---------------+--------------------+ 1 row in set (0.00 sec) 
  • Требовать ssl для подключения конкретного пользователя («require ssl»):

    • SSL

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

     GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' REQUIRE SSL; 

    To connect, the client must specify the –ssl-ca option to authenticate the server certificate, and may additionally specify the –ssl-key and –ssl-cert options. If neither –ssl-ca option nor –ssl-capath option is specified, the client does not authenticate the server certificate.


Alternate link: Lengthy tutorial here http://www.madirish.net/214

oneliner v2017:

centos:

 openssl req -x509 -nodes -sha256 -newkey rsa:2048 \ -keyout localhost.key -out localhost.crt \ -days 3650 \ -subj "CN=localhost" \ -reqexts SAN -extensions SAN \ -config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost")) 

ubuntu:

 openssl req -x509 -nodes -sha256 -newkey rsa:2048 \ -keyout localhost.key -out localhost.crt \ -days 3650 \ -subj "CN=localhost" \ -reqexts SAN -extensions SAN \ -config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost")) 
  • Как решить «Не удалось установить доверительные отношения для безопасного канала SSL / TLS с полномочиями»
  • Как проверить, подписана ли APK или «отладить сборку»?
  • Как создать самозаверяющий сертификат с помощью C #?
  • Извлечение открытого / закрытого ключа из файла PKCS12 для последующего использования в SSH-PK-аутентификации
  • Преобразование .pfx в .cer
  • Не удалось создать путь PKIX: не удалось найти допустимый путь сертификации для запрошенной цели
  • HTTPS с NSURLConnection - NSURLErrorServerCertificateUntrusted
  • Android Studio - отладочное хранилище
  • Сертификату SSL не доверяют - только на мобильных телефонах
  • Как правильно импортировать самоподписанный сертификат в хранилище ключей Java, доступное для всех приложений Java по умолчанию?
  • Как установить доверенный сертификат CA на Android-устройство?
  • Давайте будем гением компьютера.