it-swarm.com.ru

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

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

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

1077
michelemarcon

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

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

Вы также можете добавить -nodes (сокращение от no DES), если вы не хотите защищать свой закрытый ключ парольной фразой. В противном случае вам будет предложено ввести пароль как минимум из 4 символов.

Параметр days (365) можно заменить на любое число, чтобы повлиять на срок действия. Затем вам будет предложено указать такие вещи, как "Название страны", но вы можете просто нажать Enter и принять значения по умолчанию.

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

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

1793
Diego Woitasen

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

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

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

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

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

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


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

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

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

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

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

Чтобы стать вашим собственным центром сертификации, см. * Как вы подписываете запрос на подпись сертификата в своем центре сертификации? в Переполнение стека. Затем импортируйте свой CA в Trust Store, используемый браузером.

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

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

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

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


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

Приведенные ниже команды и файл конфигурации создают самозаверяющий сертификат (он также показывает, как создать запрос на подпись). Они отличаются от других ответов в одном отношении: имена DNS, используемые для самозаверяющего сертификата, находятся в альтернативном имени субъекта (SAN) , а не в Общее имя (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 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 it's 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        = [email protected]

# 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 перечислены, потому что они более строгие, чем другие документы RFC и CA/B. RFC 6797 и 7469 также не позволяют IP-адрес.

454
jww

Вот параметры, описанные в ответ @ 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 .

-keyout filename

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

-out filename

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

-days n

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

-nodes

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

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

386
user456814

Начиная с 2019 года, следующая команда удовлетворяет все ваши потребности, включая SAN:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout example.key -out example.crt -extensions san -config <(echo "[req]"; echo distinguished_name=req; echo "[san]"; echo subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1) -subj /CN=example.com

В OpenSSL ≥ 1.1.1 это можно сократить до:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout example.key -out example.crt -subj /CN=example.com -addext subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1

Это создает сертификат, который

  • действителен для доменов example.com и example.net (SAN),
  • также действителен для IP-адреса 10.0.0.1 (SAN),
  • относительно сильный (по состоянию на 2019 г.) и
  • действителен в течение 3650 дней (~ 10 лет).

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

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

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

Замечание № 1: параметры шифрования

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

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

Замечание № 2: параметр "-nodes"

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

Замечание № 3: MinGW

В Windows в bash MinGW вы должны добавить к команде префикс MSYS_NO_PATHCONV=1:

MSYS_NO_PATHCONV=1 openssl ...

Либо запустите команду в простой командной строке Windows cmd.exe.

Замечание № 4: Смотрите также

212
vog

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

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

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

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

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

  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

71
rymo

Я бы рекомендовал добавить параметр - sha256 , чтобы использовать алгоритм хеширования 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 не повышает безопасность самозаверяющего сертификата. Но я все же рекомендую использовать его как хорошую привычку не использовать устаревшие/небезопасные криптографические хеш-функции. Полное объяснение доступно в Почему нормально, если сертификаты выше сертификата конечного объекта основаны на SHA-1?.

66
Maris B.

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

<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), чтобы новый сертификат вступил в силу.

16
Drakes

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
joemillervi

Один лайнер 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]"

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

>> Подробнее здесь <<

6
OkezieE

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

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

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

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

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

У меня есть более подробная информация об этом в сообщении по адресу Защита соединения: создание сертификата безопасности с OpenSSL

6
nneko

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

Я использую /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 . Как упоминалось в предыдущих шагах ^, сохраните все наши сертификаты в виде файлов .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  |
    +---------------+----------------------------+
    
  • Проверка соединения с базой данных зашифрована 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, клиент не аутентифицирует сертификат сервера.


Альтернативная ссылка: длительный учебник в Безопасные PHP Соединения с MySQL с помощью SSL.

3
ThorSummoner

Однострочная версия 2017:

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

buntu:

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"))
3
user327843

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

Основная причина, по которой никто не хочет получать подписанный сертификат от центра сертификации, - это стоимость Symantec взимает от 995 до 1999 долларов в год за сертификаты - только за сертификат, предназначенный для внутренней сети, Symantec взимает 399 долларов в год . Эту стоимость легко оправдать, если вы обрабатываете платежи по кредитным картам или работаете в центре прибыли высокодоходной компании. Это больше, чем многие могут себе позволить для личного проекта, который каждый создает в Интернете, или для некоммерческой организации, работающей с минимальным бюджетом, или если кто-то работает в центре затрат организации - центры затрат всегда пытаются сделать больше менее.

Альтернативой является использование certbot (см. о certbot ). Certbot - это простой в использовании автоматический клиент, который получает и развертывает сертификаты SSL/TLS для вашего веб-сервера.

Если вы настроили certbot, вы можете разрешить ему создавать и поддерживать сертификат для вас, выданный центром сертификации Let’s Encrypt .

Я сделал это на выходных для своей организации. Я установил необходимые пакеты для certbot на своем сервере (Ubuntu 16.04), а затем выполнил команду, необходимую для настройки и включения certbot. Скорее всего, для certbot требуется DNS-плагин - в настоящее время мы используем DigitalOcean , хотя, возможно, скоро перейдем на другую службу.

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

В DigitalOcean я столкнулся с трудностями, когда мне было предложено ввести путь к файлу учетных данных DigitalOcean INI. Сценарий ссылается на страницу Applications & API и вкладку Tokens/Key на этой странице. Вам необходимо иметь или сгенерировать личный токен доступа (чтение и запись) для API DigitalOcean - это шестнадцатеричная строка из 65 символов. Затем эту строку необходимо поместить в файл на веб-сервере, с которого вы запускаете certbot. Этот файл может содержать комментарий в качестве первой строки (комментарии начинаются с #). Вторая строка:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

Как только я понял, как настроить токен чтения + записи для API DigitalOcean, было довольно легко использовать certbot для установки подстановочный сертификат . Обратите внимание, что не нужно настраивать подстановочный сертификат, вместо этого можно указать каждый домен и поддомен, к которому требуется применить сертификат. Это был подстановочный сертификат, для которого требовался файл INI учетных данных, содержащий личный токен доступа от DigitalOcean.

Обратите внимание, что сертификаты открытых ключей (также известные как сертификаты идентификации или сертификаты SSL) истекают и требуют обновления. Таким образом, вам необходимо будет обновлять свой сертификат на периодической (повторяющейся) основе. Документация certbot охватывает обновление сертификатов .

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

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

[email protected]:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT
2
Peter Jirak Eldritch

Сценарии самоподписанного сертификата и цепочки сертификатов для RSA и ECDSA с использованием OpenSSL доступны здесь.

0
rashok