Автор: Джэми Нгуен (Jamie Nguyen)
Работа в качестве удостоверяющего центра (CA) подразумевает использование криптографических пар приватных ключей и публичных сертификатов. Самая первая криптографическая пара, которую мы создадим - это корневая пара. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует удостоверение удостоверяющего центра.
Обычно корневой удостоверяющий центр не подписывает непосредственно сертификаты сервера или клиента. Корневой удостоверяющий центр используется только для создания одного или более промежуточных удостоверяющих центров, которым корневой удостоверяющий центр доверяет подписывать сертификаты от своего имени. Это лучшая практика. Она позволяет корневому ключу храниться автономно и использоваться как можно реже, потому что компрометация корневого ключа очень опасна.
Замечание. Лучшей практикой считается создание корневой пары в безопасной среде. Лучше всего, если это будет полностью зашифрованный компьютер, постоянно отключенный от Интернета. Лучше даже изъять из него беспроводные карты и залить клеем Ethernet-порты.Подготовка каталога
Выберем каталог (/root/ca) для хранения всех ключей и сертификатов.
# mkdir /root/caСоздадим структуру каталогов. Файлы index.txt и serial выступают в роли плоской базы данных для отслеживания подписанных сертификатов.
# cd /root/ca # mkdir certs crl newcerts private # chmod 700 private # touch index.txt # echo 1000 > serialПодготовка файла конфигурации
Нужно создать файл конфигурации, который будет использоваться OpenSSL. Скопируем файл конфигурации корневого удостоверяющего центра из Приложения А в файл /root/ca/openssl.cnf.
Раздел [ca] обязателен. Здесь мы сообщаем OpenSSL, что нужно использовать опции из раздела [CA_default].
[ca] # `man ca` default_ca = CA_defaultРаздел [CA_default] содержит набор значений по умолчанию. Убедитесь, что указан выбранный ранее каталог (/root/ca).
[CA_default] # Местонахождение каталогов и файлов dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # Корневой ключ и корневой сертификат private_key = $dir/private/ca.key.pem certificate = $dir/certs/ca.cert.pem # Настройки списков отозванных сертификатов crlnumber = $dir/crlnumber crl = $dir/crl/ca.crl.pem crl_extensions = crl_ext default_crl_days = 30 # SHA-1 устарел, поэтому используем вместо него SHA-2 default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_strictМы применим строгую политику policy_strict для всех подписей корневого удостоверяющего центра, потому что корневой удостоверяющий центр используется только для создания промежуточных удостоверяющих центров.
[policy_strict] # Корневой удостоверяющий центр должен подписывать только соответствующие промежуточные сертификаты # Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca` countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optionalМы применим свободную политику policy_loose для всех подписей промежуточных удостоверяющих центров, потому что промежуточные удостоверяющие центры подписывают сертификаты серверов и клиентов, которые могут поступать от разнообразных сторонних лиц.
[policy_loose] # Разрешим промежуточному удостоверяющему центру подписывать более широкий диапазон сертификатов # Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca` countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optionalОпции из раздела [req] применяются при создании сертификатов или запросов на подпись сертификата.
[req] # Опции утилиты `req` (`man req`) default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 устарел, поэтому используем вместо него SHA-2 default_md = sha256 # Расширения, добавляемые при использовании опции -x509 x509_extensions = v3_caРаздел [req_distinguished_name] объявляет информацию обычно требуемую в запросе на подпись сертификата. Можно указать дополнительные значения по умолчанию.
[req_distinguished_name] # Обратитесь к https://en.wikipedia.org/wiki/Certificate_signing_request countryName = Название страны (двухбуквенный код) stateOrProvinceName = Название штата или провинции localityName = Название местности 0.organizationName = Название организации organizationalUnitName = Название подразделения организации commonName = Общее имя emailAddress = Адрес электронной почты # На выбор, можно указать несколько значений по умолчанию countryName_default = GB stateOrProvinceName_default = England localityName_default = 0.organizationName_default = Alice Ltd #organizationalUnitName_default = #emailAddress_default =Следующие несколько разделов - это расширения, которые могут быть применены при подписывании сертификатов. Например, передача аргумента командной строки -extensions v3_ca применит опции из набора в разделе [v3_ca].
При создании корневого сертификата применим расширение v3_ca.
[v3_ca] # Расширения для типичного удостоверяющего центра (`man x509v3_config`) subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSignПри создании промежуточного сертификата применим расширение v3_ca_intermediate. pathlen:0 гарантирует, что у промежуточного удостоверяющего центра не будет дочерних промежуточных удостоверяющих центров.
[v3_intermediate_ca] # Расширения для типичного промежуточного удостоверяющего центра (`man x509v3_config`) subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSignРасширение usr_cert будем применять при подписании клиентских сертификатов, которые будут использоваться для аутентификации удалённых пользователей.
[usr_cert] # Расширения для клиентских сертификатов (`man x509v3_config`) basicConstraints = CA:FALSE nsCertType = client, email nsComment = "Сертификат клиента создан OpenSSL" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtectionПрименим расширение server_cert при подписании сертификатов серверов, например, используемых веб-серверами.
[server_cert] # Расширения для сертификатов серверов (`man x509v3_config`) basicConstraints = CA:FALSE nsCertType = server nsComment = "Сертификат сервера создан OpenSSL" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuthРасширение crl_ext применяется автоматически при создании списков отозванных сертификатов.
[crl_ext] # Расширение для списков отозванных сертификатов (`man x509v3_config`) authorityKeyIdentifier = keyid:alwaysПрименим расширение ocsp при подписании сертификата для протокола интерактивного статуса сертификата (Online Certificate Status Protocol - OCSP).
[ocsp] # Расширение для подписи сертификатов OCSP (`man ocsp`) basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigningСоздание корневого ключа
Создадим корневой ключ (ca.key.pem) и сохраним его в полной безопасности. Злоумышленник, заполучивший корневой ключ, сможет выпускать доверенные сертификаты. Зашифруйте корневой ключ при помощи 256-битного шифрования AES и сильного пароля.
Замечание. Используйте 4096 бит для всех корневых и промежуточных ключей удостоверяющих центров. Вы по-прежнему сможете подписывать сертификаты серверов и клиентов более короткой длины.
# cd /root/ca # openssl genrsa -aes256 -out private/ca.key.pem 4096 Enter pass phrase for ca.key.pem: secretpassword # Введите ключевую фразу для ca.key.pem: секретныйпароль Verifying - Enter pass phrase for ca.key.pem: secretpassword # Проверка - Введите ключевую фразу для ca.key.pem: секретныйпароль # chmod 400 private/ca.key.pemСоздание корневого сертификата
Воспользуемся корневым ключом (ca.key.pem) для создания корневого сертификата (ca.cert.pem). Примем срок действия корневого сертификата достаточно длинным, например - двенадцать лет. По истечении срока действия корневого сертификата все сертификаты, подписанные этим удостоверяющим центром, станут недействительными.
Предупреждение! При каждом использовании утилиты req нужно указывать используемый файл конфигурации с помощью опции -config, в противном случае OpenSSL будет использовать файл по умолчанию /etc/pki/tls/openssl.cnf.
# cd /root/ca # openssl req -config openssl.cnf \ -key private/ca.key.pem \ -new -x509 -days 7300 -sha256 -extensions v3_ca \ -out certs/ca.cert.pem Enter pass phrase for ca.key.pem: secretpassword # Введите ключевую фразу для ca.key.pem: секретныйпароль You are about to be asked to enter information that will be incorporated # У вас будет запрошена информация, которая будет вставлена into your certificate request. # в ваш запрос сертификата. ----- Country Name (2 letter code) [XX]:GB # Название страны (двухбуквенный код) [XX]:GB State or Province Name []:England # Название штата или провинции []:Англия Locality Name []: # Название местности []: Organization Name []:Alice Ltd # Название организации []:ООО Алиса Organizational Unit Name []:Alice Ltd Certificate Authority # Название подразделения []:Удостоверяющий центр ООО Алиса Common Name []:Alice Ltd Root CA # Общее имя []:Корневой удостоверяющий центр ООО Алиса Email Address []: # Адрес электронной почты []: # chmod 444 certs/ca.cert.pemПроверка корневого сертификата
# openssl x509 -noout -text -in certs/ca.cert.pemВ выводе будут отображены:
- используемый алгоритм подписания,
- даты действия сертификата,
- битовая длина публичного ключа,
- эмитент, который подписал этот сертификат,
- субъект, который относится к этому сертификату.
Signature Algorithm: sha256WithRSAEncryption # Алгоритм подписания: sha256WithRSAEncryption Issuer: C=GB, ST=England, # Эмитент: C=GB, ST=Англия, O=Alice Ltd, OU=Alice Ltd Certificate Authority, # O=ООО Алиса, OU=Удостоверяющий центр ООО Алиса, CN=Alice Ltd Root CA # CN=Корневой удостоверяющий центр ООО Алиса Validity # Действительность Not Before: Apr 11 12:22:58 2015 GMT # Не ранее: 11 апреля 2015 года в 12:22:58 по Гринвичу Not After : Apr 6 12:22:58 2035 GMT # Не позднее: 6 апреля 2035 года 12:22:58 по Гринвичу Subject: C=GB, ST=England, # Субъект: C=GB, ST=Англия, O=Alice Ltd, OU=Alice Ltd Certificate Authority, # O=ООО Алиса, OU=Удостоверяющий центр ООО Алиса, CN=Alice Ltd Root CA # CN=Корневой удостоверяющий центр ООО Алиса Subject Public Key Info: # Информация публичного ключа субъекта: Public Key Algorithm: rsaEncryption # Алгоритм публичного ключа: rsaEncryption Public-Key: (4096 bit) # Публичный ключ: (4096 бит)В выводе также отображаются расширения X509v3. Мы применили расширение v3_ca, поэтому в выводе должны отобразиться опции из [v3_ca].
X509v3 extensions: # Расширения X509v3: X509v3 Subject Key Identifier: # Идентификатор ключа субъекта X509v3: 38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31 X509v3 Authority Key Identifier: # Идентификатор ключа подлинности X509v3: keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31 X509v3 Basic Constraints: critical # Базовые ограничения X509v3: критично CA:TRUE X509v3 Key Usage: critical # Использование ключа X509v3: критичное Digital Signature, Certificate Sign, CRL Sign # Цифровая подпись, подписание сертификата, подписание списка отозванных сертификатов
8 комментариев:
Доброго времени суток.
Можете подсказать, будут ли работать сертификаты для базы данных mysql или это только для HTTPS?
Дмитрий, будут работать. В MySQL используются сертификаты в формате PEM. Большинство веб-серверов тоже используют этот формат.
Вот что интересно. Сделал, все как тут написано. В ответ получаю ошибку ERROR 2026 (HY000): SSL connection error: error:00000000:lib(0):func(0):reason(0).
Да, это действительно интересно. Но в этой статье нет ни слова про настройку SSL в MySQL. Здесь рассматривается настройка корневого сертификата удостоверяющего центра. Создание сертификатов серверов рассматривается в одной из следующих статей. Возможно вам не нужен удостоверяющий центр, а нужна статья про настройку SSL в MySQL? Тогда посмотрите куда-нибудь сюда:
http://cyber01.ru/manuals/rabota-mysql-s-ssl/
https://habrahabr.ru/post/104412/
Меня интересует только один вопрос. Собственно ища ответ на него, попал на оригинал этой статьи, потом попал на вашу статью. А, вопрос заключается в следующем. Как мне организовать CRL на Mysql, таким образом, чтобы когда я добавляю в список CRL скомпрометированный сертификат, чтобы по этому сертификату нельзя было подключиться к серверу, как локально так и с других машин?
У меня получается создать сертификаты, создать CRL.pem в который я добавляют удаленные сертификаты и когда находясь на этом же компе, где локально лежит этот файл(crl.pem) я не могу подключиться к БД, что очень хорошо. Но, стоит взять этот удаленный сертификат и подключиться с ним с другой машины, где не будет crl.pem и там вообще будет только клиент БД, то подключение удается и я нахожусь внутри БД сервера. Ни, каких надстроек не делал над openssl.cnf.
Насколько я понимаю, вы хотите отзывать сертификаты клиентов, чтобы сервер MySQL не пускал клиентов с отозванными сертификатами.
В таком случае серверу MySQL нужно указать файл, откуда он будет брать список отозванных сертификатов. Почитайте тогда материал по этой ссылке:
https://dev.mysql.com/doc/refman/5.7/en/secure-connection-options.html
Там упоминаются такие вот опции:
--ssl-crl Path of file that contains certificate revocation lists
--ssl-crlpath Path of directory that contains certificate revocation list files
Насколько я понимаю, эти же опции можно указать и в файле /etc/mysql/my.cnf, записав их таким вот образом:
ssl-crl=
ssl-crlpath=
На стороне клиента можно проверять, был ли отозван сертификат сервера. Не думаю, что вам нужно именно это. С этим уже сложнее - по идее сам клиент должен скачивать список отозванных сертификатов по протоколу HTTP по той ссылке, которая указана в самом сертификате сервера. Но, возможно, для этого нужно использовать те же опции --ssl-crl или --ssl-crlpath клиенту mysql. Сам я SSL в MySQL не настраивал, поэтому уверенно подсказать что и как нужно делать не смогу.
Спасибо. Вы все верно сказал. Нужно в конфиг файле my.cnf указать в
[mysqld]
...
ssl-crl=/путь/до/crl.pem
...
[mysql]
...
ssl-crl=/путь/до/crl.pem
...
И, вот этого уже будет достаточно.
Потом, я столкнулся с проблемой, которую выше озвучил.
И, понял, что для того, чтобы другие подключаясь по старым(отозванным) сертификатам не могли попасть в БД, нужно дописать в файл конфиг. openssl.cnf
crlDistributionPoints = URI:http://domen.ru/crl.pem
и если потом просмотреть, содержимое файла с сертификатом, то будет виден это адрес. Но, видимо нужно еще, что-то прописать в конфиге Openssl.cnf или еще где, чтобы все это заработало. Я так и не разобрался в этом.
Ну, да ладно, спасибо, что выделили время на меня.
Вот тут описывается такая же ошибка, как у вас: https://dev.mysql.com/doc/refman/5.7/en/creating-ssl-files-using-openssl.html
Пишут, что у сертификатов клиента, сервера и удостоверяющего центра должны отличаться друг от друга значения в полях Common Name.
От себя добавлю, что у клиентского сертификата и у сертификата удостоверяющего центра там может быть любое имя, а у серверного сертификата там должно быть доменное имя сервера. Клиенту MySQL нужно для подключения указывать имя сервера, тогда он из него через DNS узнает IP-адрес, подключится к этому IP-адресу и получит от сервера сертификат. Если в сертификате указано именно это доменное имя сервера, которое использовалось для подключения, и в остальном сертификат годный (подписан удостоверяющим центром, который известен клиенту и все сертификаты в цепочке годны по сроку действия), то подключение должно установиться.
Отправить комментарий