Как создать самозаверяющий сертификат с 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:

Это, вероятно, не тот сайт, который вы ищете!
Сертификат безопасности сайта не является доверенным!

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

895
certificate openssl ssl ssl-certificate x509certificate

13 ответов

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

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

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

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

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

1555

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

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

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

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

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

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

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

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

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

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

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

чтобы стать вашим собственным центром сертификации, см. как вы подписываете запрос на подписание сертификата с вашим центром сертификации? при переполнении стека. Затем импортируйте CA в хранилище доверия, используемое браузером.

шаги 2 - 4 примерно что теперь вы делаете это для общедоступного сервера, когда вы привлекаете услуги ЦС, такие как Startcom или CAcert. Шаги 1 и 5 позволяют вам избегать авторитета третьей стороны и действовать как свой собственный авторитет (кому лучше доверять, чем себе?).

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

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

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

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

команды ниже и файл конфигурации создают самозаверяющий сертификат (он также показывает, как создать запрос подписи). Они отличаются от других ответов в одном отношении: DNS-имена, используемые для самозаверяющего сертификата, находятся в тема альтернативное имя (SAN), а не общий 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 определяют практику. Они также указывают, что DNS-имена в CN являются устаревшими (но не запрещенными). если вы ставите DNS-имя в CN, затем это должны быть включены в SAN в соответствии с политикой CA/B. Поэтому вы не можете избежать использования альтернативного имени субъекта.

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

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

создать самозаверяющий сертификат (обратите внимание на добавление ):

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

создать запрос на подпись (уведомление отсутствие ):

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

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

[ 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 (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = test@example.com

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., 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. I.e., 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 6797 и RFC 7469 перечислены, потому что они являются более ограничительными, чем другие документы RFCs и CA/B. RFC 6797 и 7469 не разрешить IP-адрес, либо.

401

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

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

req

PKCS#10 запрос сертификата и утилита генерации сертификатов.

-x509

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

-newkey arg

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

-keyout filename

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

-out filename

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

-days n

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

-nodes

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

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

364

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

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 будет зашифрован паролем. Однако это почти никогда не полезно для установки сервера, потому что вам придется либо хранить пароль на сервере, либо вводить его вручную при каждой перезагрузке.

121

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

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

вот упрощенная версия, которая удаляет парольную фразу, повышает безопасность для подавления предупреждений и включает предложение в комментариях передать in-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 запросит парольную фразу.

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

cat server.crt server.key > cert.pem
110

Я бы рекомендовал добавить -SHA256 и параметр, чтобы использовать алгоритм хэша SHA-2, потому что основные браузеры рассматривают возможность показать" сертификаты SHA-1 " как небезопасные.

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

OpenSSL требуе -x509 в -SHA256 и - newkey rsa:2048-ключ ключа.Пем-аут сертификат.pem-days XXX

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

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

64

современные браузеры теперь выдают ошибку безопасности для хорошо сформированных самозаверяющих сертификатов, если у них отсутствует SAN (альтернативное имя субъекта). 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

60

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

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

хром 58 поступательный требует сан в самоподписанный сертификаты.

#!/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 = webmaster@$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"

этот скрипт также записывает файл info, чтобы вы могли проверить новый сертификат и убедиться, что 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, то вы можете ссылаться на вышеуказанный сертификат в вашем файле конфигурации следующим образом:

<VirtualHost _default_:443>
    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
</VirtualHost>

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

12

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 файлы, если это необходимо.

9

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

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

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

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

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

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

5

один вкладыш 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/emailAddress=someEmail@gmail.com"

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

>> здесь

4

генерировать ключи

я использую /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

в моей настройке сервер ubuntu вошел в систему:/var/log/mysql/error.log

последующие ноты:

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

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

  • SSL error: Unable to get private key

    ваша версия сервера mysql может не поддерживать значение по умолчанию .

    Covert generated 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  |
+---------------+----------------------------+

  • проверка соединения с БД зашифрована 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)

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

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

  • требуется ssl для подключения конкретного пользователя ('требуется ssl'):

    • протокол SSL

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

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

    для подключения клиент должен указать параметр --ssl-ca для аутентификации сертификат сервера и может дополнительно указать параметры --ssl-key и --ssl-cert. Если параметр --ssl-ca или --ssl-capath не указан, клиент не проверяет подлинность сертификата сервера.

альтернативная ссылка: длинный учебник здесь http://www.madirish.net/214

2

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"))
2