What is the Subject Alternative Name (SAN)? – DNSimple Help

Вступление

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

Центр сертификации (CA) является объектом, который подписывает цифровые сертификаты. Многие веб-сайты нуждаются в том, чтобы их клиенты знали, что соединение является безопасным, поэтому они платят международным доверенным центрам сертификации (например, VeriSign, DigiCert) за подпись сертификата для своего домена.

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

Что нужно сделать чтобы установить ssl-сертификат

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

1. приобрести SSL-сертификат;
2. сгенерировать CSR запрос на сертификат;
3. выпустить SSL-сертификат;
4. установить SSL-сертификат на хостинг или сервер;
5. внести изменения в настройки сайта.

Background

The X.509 specifications regulate the Internet X.509 Public Key Infrastructure Certificate, which includes the SSL certificates format. Originally, SSL certificates only allowed the designation of a single host name in the certificate subject called Common Name.

The common name represents the host name that’s covered by the SSL certificate. Trying to use the certificate for a website that doesn’t match the common name will result in a security error, also known as host name mismatch error.

Csr запрос ssl сертификата

При покупке SSL сертификата при помощи специальных утилит или сервисов генерируется CSR запрос (Certificate Signing Request) в котором закодированы следующие данные:

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

Ниже пример публичной части такого CSR запроса, в котором закодированы указанные выше данные:

-----BEGIN CERTIFICATE REQUEST-----
MIICyDCCAbACAQAwgYIxCzAJBgNVBAYTAlVBMQ0wCwYDVQQIDARLaWV2MQ0wCwYD
VQQHDARLaWV2MQ4wDAYDVQQKDAVlbGltUzELMAkGA1UECwwCSVQxFTATBgNVBAMM
DGVsaW1zLm9yZy51YTEhMB8GCSqGSIb3DQEJARYSYWRtaW5AZWxpbXMub3JnLnVh
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvcvusWoQJ iVE9Z8bD6F
k00/GMiwLNi mR0EJwp2TGybVgUnydlK2FV8o0091ZuGrkniwnoimX 8N4ATzem1
jMeXlScqmLdWL2R6DnUTWHiIWezAmyIO51gBiMJ0E jbfnauog2rNXTgGZbzJRvR
7y8hnL10DYtCfbCObxERynJWzxBFmK0qm8NREMMTa1dZGgmT7e9 afLMaKYqLlcM
DGQNvIQyehI4g8aQwS2OJ7JuTcTXMusWjSQFIMeleg8nkuWJZ6awtTN6Rubh/VHI
XO7LC4zdo8xzo8ub4calLSwi5Flr5iZUyzYxrqj2raBQ9pH1nCCyczlkH6I1HaHq
nwIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAG2HoDX4zfmk331tp VCEIpGooUt
1EgwGLf73SD7x7ZH6K0fe44cKECmc//Gdvr3UObckYw/aMgR88eGmWnpkjhGz0kX
IfCqpK5zkoaBihofbs1G8 liuocvnMtKCphH/56GPAxPG/K7breJMGiaEkAq0Axn
ozbvvSBbzILdV7xygSib6D20rvdsNOh7fKzo0bSgBhizuQ4/c0uPCTRzFrOvVVNW
mY1NPF4IkurN2iEhbrGlJbKTki SNh8oRrLyXDzqJE8QcZHKnO69JECGMTjhCDGI
Kr/rxRB/p7qmlCUqhlVS2A6NhicKvAs s9gE8BZE4uKXtp5vaOXxlJofpC0=
-----END CERTIFICATE REQUEST-----

Раскодировать CSR и посмотреть что в нем зашифровано, например при помощи этих сервисов:

Или утилиты openssl и команды:

openssl req -in mycsr.csr -noout -text

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

Создать CSR с новым сертификатом через утилиту OpenSSL

openssl req -new -newkey rsa:2048 -nodes -keyout domain_name.key -out domain_name.csr

Mac os x

Safari, FireFox, Chrome — используют системный репозиторий.

Запускаем KeyChain Access.Идём в меню File — Import Items (login или System) — выбираем файл rootCA.crt.Когда нас спросят, отвечаем — Always Trust.

Для вашего личного Safari достаточно выбрать login.

Online certificate status protocol

Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.

Openssl certificate authority. центр сертификации openssl.

Вольный перевод с источника

Эта инструкция демонстрирует, как работает собственный центр сертификации (CA – Certificate Authority), используя набор инструментов командной строки OpenSSL. Это полезно в ряде случаев, таких как выдача сертификата сервера для защиты вебсайта в интранете, или для выдачи сертификатов для клиентов, чтобы позволить им проверить подлинность сервера.

San certificates

A SAN certificate is a term often used to refer to a multi-domain SSL certificate. An SSL certificate with more than one name is associated using the SAN extension.

There’s a subtle difference though. When using the term ‘multi-domain certificates’, we’re generally referring to an SSL certificate that has the ability to cover multiple host names (domains). If we use the term ‘SAN certificates’, we’re probably referring to a particular certificate that includes any name in the SAN extension.

From a technical standpoint, every certificate issued today is effectively a SAN certificate, as the CA/B forum requires the certification authority to add the content of the common name to the SAN as well. Even if the certificate covers a single name, it will still use the SAN extension and include that single name.

In practice, the terms ‘SAN certificates’ and ‘multi-domain certificates’ are synonymous, and generally indicate a certificate product where issuers can associate more than one domain by specifying the content of the SAN (directly or indirectly). These certificates are often marketed as “special” and priced differently than standard certificates, because you can associate more than one name.

San certificates and dnsimple

DNSimple provides SAN SSL certificates issued by the Let’s Encrypt certification authority.

For current platform limitation, all the names must belong to the same domain:

San restrictions

There’s no specific limitation on the host names you can cover with a SAN extension, besides the requirement to be syntactically valid host names (further details are available in the RFC). However, certificate authorities may impose further limitations on the number or formats based on internal rules or business decisions.

For example, it’s common practice to disallow arbitrary wildcard names as SAN host names. This means SAN certificates generally support only a specific list of names.

It’s also common to encounter a limit on the number of names per certificate, usually up to 100.

Finally, names are generally not required to belong to the same domain. It’s fine for a certificate to cover a list of names like this:

San сертификаты

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

Цена: от 395 $ в год

Sgc сертификаты

Сертификаты с поддержкой повышения уровня шифрования. Актуально для очень старых браузеров, которые поддерживали только 40 или 56 бит шифрование. При использовании этого сертификата уровень шифрования принудительно повышается до 128 бит.

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

Цена: от 300 $ в год.

Windows

IE, Chrome — используют репозиторий сертификатов Windows.

Мой путь к нему таков:

Chrome — Settings — Manage Certificates…Выбрать таб Trusted Root Certificate Authorities — Import — rootCA.crtперезапустить Chrome

FireFox на виндоус имеет свой репозиторий.

Java имеет свой репозиторий.

В ubuntu

sudo mkdir /usr/share/ca-certificates/extra
sudo cp rootCA.crt /usr/share/ca-certificates/extra/rootCA.crt
sudo dpkg-reconfigure ca-certificates
sudo update-ca-certificates

Выпуск ssl-сертификата

Теперь, когда есть запрос, на основании него можно выпустить сертификат.

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

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

Генератор конфигурационных файлов ssl

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

Генерация csr запроса на собственном сервере

Потребуется криптографический пакет с открытым исходным кодом – . Он входит в состав большинства UNIX-подобных операционных систем.

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

Подключитесь к серверу по SSH и перейдите в домашнюю директорию.

cd ~

Сгенерируйте закрытый ключ.

openssl genrsa -out private.key 4096

В команде выше:

• private.key – выходной файл, который будет содержать ключ;
• 4096 – размер ключа, резже 2048.

На запрос «Enter pass phrase for private.key» укажите пароль для защиты закрытого ключа, а затем «Verifying – Enter pass phrase for private.key» – подтвердите его, повторив ввод пароля еще раз.

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

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

Далее сгенерируйте CSR запрос.

openssl req -new -key private.key -out domain.csr -sha256

В команде выше:

• private.key – созданный на предыдущем этапе закрытый ключ;
• domaine.csr – выходной файл с CSR запросом.

На запрос «Enter pass phrase for private.key» введите пароль от закрытого ключа.

Далее последовательно латинскими символами укажите следующие данные:

CSR запрос на сертификат будет сохранен в файле domain.csr в виде закодированного текста.

Проверить корректность введенных данных можно, выполнив следующую команду.

openssl req -noout -text -in domain.csr

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

less private.key

или

less domain.csr

Для выхода нажмите клавишу Q.

Генерация запроса на получение сертификата для microsoft iis

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

Генерация CSR для Microsoft IIS 5.x/6.xГенерация CSR для Microsoft IIS 7.xГенерация CSR для Microsoft IIS 8.0

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

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

Есть ли разница в каком центре сертификации заказывать сертификат?

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

Что касается перечисленных выше центров сертификации, то их корневые сертификаты установлены в, пожалуй, 99,99% всех существующих браузеров.

Чтобы проверить, корневые сертификаты каких центров сертификации установлены в вашем браузере, достаточно в настройках вашего браузера найти такую опцию. (В Chrome Настройки -> показать дополнительные настройки -> управление сертификатами ->

Важный момент — частенько у клиентов возникала ситуация, когда SSL сертификат на серверe установлен, но при заходе на сайт браузер все равно выдает ошибку. Такая ситуация может возникнуть или из-за отсутствия в файле ca-bundle.crt корневого сертификата центра выдавшего сертификат или из-за того, что корневой сертификат устарел. Корневые сертификаты также имеют свой срок действия (в браузерах они обновляются при обновлении браузера).

Ипользование crl на сервере

Обычно серверное приложение (к примеру, Apache) делает проверку для клиентских сертификатов.Это приложение должно иметь локальный доступ до CRL.

В случае Алисы, она может добавить директиву SSLCARevocationPath в ее конфигурацию Apache и скопировать CRL на свой сервер. В следующий раз, когда Боб подключится к веб-серверу, Apache проверит его клиентский сертификат в CRL и запретит доступ. По аналогии, OpenVPN имеет директиву crl-verify, и можно блокировать клиентов, чьи сертификаты были отозваны.

Использование crl клиентами

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

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

Точки распространения CRL видны в спецификациях X509v3 сертификата.

Как выбрать самый дешевый сертификат?

У Geotrust самые дешевые SAN сертификаты. Сертификаты с валидацией только сайта, а также wildcard выгоднее всего у RapidSSL. EV сертификаты самые дешевые также у Geotrust. SGC сертификаты есть только у Thawte и Verisign, но у Thawte дешевле.

Как проверить соответствие ssl сертификата и csr к приватному ключу

Нужно преобразовать приватный ключ, SSL сертификата и CSR в md5 хэши:

Вывести md5 хэш модуля SSL сертификата :

$ openssl x509 -noout -modulus -in CERTIFICATE.crt | openssl md5

Вывести md5 хэш модуля приватного ключа :

$ openssl rsa -noout -modulus -in PRIVATEKEY.key | openssl md5

Вывести md5 хэш модуля CSR :

$ openssl req -noout -modulus -in CSR.csr | openssl md5

Если полученные md5 хэши одинаковы, значит файлы (сертификат, приватный ключ и CSR) соответствую друг другу.

Как установить ssl-сертификат в панели управления ispmanager

Войдите в панель управления ISPmanager.

Перейдите в раздел «SSL-сертификаты» и нажмите «Создать».

Укажите тип сертификата «Существующий» и нажмите «Далее».

На открывшейся странице заполните поля:

• Имя SSL-сертификата – любое имя латиницей, под ним сертификат будет отображаться в панели управления;
• SSL-сертификат – содержимое файла SSL-сертификата;
• Ключ SSL-сертификата – приватный ключ сертификата;
• Цепочка SSL-сертификатов – последовательно укажите сначала корневой сертификат, а затем с новой строки без пробела – промежуточный.

Затем нажмите Завершить.

В разделе «SSL-сертификаты» появится добавленный сертификат.

Как установить ssl-сертификат на сервер с apache

Понадобится файл SSL-сертификата, назовите его domain.crt и приватный ключ, который был получен на этапе генерации CSR запроса на сертификат, переименуйте его в domain.key.

Так же, создайте текстовый документ, например с именем chain.crt и поместите в него цепочку сертификатов — поочередно добавьте в него содержимое промежуточного сертификата и следом за ним корневого (без лишних пробелов и пустых строк).

Все 3 файла загрузите на сервер в директорию /etc/ssl/

Откройте конфигурационный файл Apache сайта, для которого устанавливается сертификат. Если сайт один, конфигурационный файл скорее всего будет одним из указанных ниже:

Как установить ssl-сертификат на сервер с nginx

Объедините три сертификата (SSL-сертификат, корневой и промежуточный) в один файл. Для этого с помощью блокнота или другого редактора создайте текстовый документ с именем domain.crt и поочередно поместите в него содержимое каждого из сертификатов (без лишних пробелов и пустых строк).

-----BEGIN CERTIFICATE-----
#SSL-сертификат#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#Корневой сертификат#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#Промежуточный сертификат (один или несколько)#
-----END CERTIFICATE-----

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

Оба файла загрузите на сервер в директорию /etc/ssl/ или /etc/nginx/ssl/

Отредактируйте виртуальный хост сайта, для которого устанавливается сертификат. Файл /etc/nginx/sites-available/site.conf или или другой, в зависимости от особенностей сервера.

Как установить ssl-сертификат на хостинг

Найдите раздел SSL панели управления хостингом.

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

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

Аналогичным образом процедура выглядит для других хостеров. На скриншоте ниже скриншот с примером для Hostland.

Подробные инструкции можно найти у своего хостинг провайдера.

Обычные ssl сертификаты

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

Цена: от 20$ в год

Подготовка каталогов

Файлы корневого центра сертификации хранятся в /root/ca. Выберем каталог (/root/ca/intermediate) для хранения файлов промежуточного центра сертификации.

# mkdir /root/ca/intermediate

Создадим точно такую же структуру каталогов, которая используется для корневого центра сертификации. Также удобно создать каталог csr для хранения запросов на подпись сертификатов.

Подготовка конфигурационного файлы

Для использования OCSP центр сертификации должен закодировать расположение сервера OCSP в сертификат, который он подписывает. Используем опцию authorityInfoAccess в соответствующей секции, в нашем случае в секции server_cert.

Подготовка конфигурационных файлов

Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf, скопируем в него следующее содержимое root-config.txt.Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default]:

[ ca ]
#man ca
default_ca = CA_default

Раздел [CA_default] содержит ряд значений по умолчанию:

[ CA_default ]
# Directory and file locations.
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

# The root key and root certificate.  
 private_key       = $dir/private/ca.key.pem  
 certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.  
 crlnumber         = $dir/crlnumber  
 crl               = $dir/crl/ca.crl.pem  
 crl_extensions    = crl_ext  
 default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.  
 default_md        = sha256

name_opt          = ca_default  
 cert_opt          = ca_default  
 default_days      = 375  
 preserve          = no  
 policy            = policy_strict

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

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of man ca.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

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

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.  
default_md          = sha256

# Extension to add when the -x509 option is used.  
x509_extensions     = v3_ca

Секция [ req_distinguished_name ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.

Подготовка файла конфигурации

Когда центр сертификации подписывает сертификат, он обычно зашифровывает расположение CRL в сертификат. Добавляется crlDistributionPoints в подходящие секции. В нашем случае, добавляет к секции server_cert.

Подписывание серверного и клиентского сертификатов

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

Указанные ниже шаги с вашей точки сзрения, где вы выступаете в качестве центра сертификации. Стороннее лицо, однако, вместо этого может создать свой собственный частный ключ и запрос на подпись сертификата (CSR) без раскрытия вам своего частного ключа. Они дают вам собственный CSR, а вы отдаете им подписанный сертификат. В этом случае, пропустите команды genrsa и req.

Полезная информация

Получить сертификат Active Directory можно при помощи ввода команды на контролере домена:

certutil -ca.cert cacert.bin

Генерация приватного 2048-битного ключа при помощи openssl:

openssl genrsa -out privat.key 2048

Пример config-файла утилиты OpenSSL для генерации SAN сертификата:

Приобретение ssl-сертификата

Итак, вы знаете, что такое SSL и определились в выборе сертификата, далее его нужно приобрести.

Купить SSL-сертификат можно напрямую у одного из удостоверяющих центров, например , , . Однако проще всего это сделать у вашего хостинг-провайдера, где располагается домен, сервер, сайт.

Рекомендую хостинги:

• (промокод на скидку для заказа домена или хостинга: 2229-CC0A-AC4D-C31B)
• (месяц бесплатно)

На этапе покупки укажите тип сертификата и домен для которого он приобретается. Затем оплатите сертификат.

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

Проверка корневого сертификата

# openssl x509 -noout -text -in certs/ca.cert.pem

Вывод показывает:

• Используемый алгоритм Signature Algorithm
• Даты периода действия сертификата Validity
• Длину публичного ключа Public-Key
• Эмитент сертификата Issuer, который является объектом, который подписал сертификат
• Предмет Subject, который относится к самому сертификату.

Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.

Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Validity
Not Before: Apr 11 12:22:58 2021 GMT
Not After : Apr  6 12:22:58 2035 GMT
Subject: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)

Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca, и опции из секции [ v3_ca ] отражены в выводе.

X509v3 extensions:
X509v3 Subject Key Identifier:
38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Authority Key Identifier:
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
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign

Проверка промежуточного сертификата

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

# openssl x509 -noout -text 
-in intermediate/certs/intermediate.cert.pem

Сверим промежуточный сертификат с корневым сертификатом. ОК показывает, что цепочка доверия не повреждена.

# openssl verify -CAfile certs/ca.cert.pem 
intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK

Процесс выдачи сертификатов ov

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

Сертификаты c поддержкой idn

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

Сертификаты с валидацией организации.

В таком сертификате уже будет указано название организации. Такой сертификат частное лицо получить не может. Срок выдачи таких сертификатов как правило от 3 до 10 рабочих дней, зависит от центра сертификации.

Сертификаты, подтверждающие только домен

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

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

Создаем сертификат подписаный нашим са

Генерируем ключ.

openssl genrsa -out server101.mycloud.key 2048

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

openssl req -new -key server101.mycloud.key -out server101.mycloud.csr

Тут важно указать имя сервера: домен или IP (например домен

server101.mycloud

Common Name (eg, YOUR name) []: server101.mycloud

и подписать запрос на сертификат нашим корневым сертификатом.

openssl x509 -req -in server101.mycloud.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server101.mycloud.crt -days 5000

Теперь на клиенты нужно установить корневой сертификат rootCA.crt

rootCA.crt — можно давать друзьям, устанавливать, копировать не сервера, выкладывать в публичный доступrootCA.key — следует держать в тайне

Создание crl

# cd /root/ca
# openssl ca -config intermediate/openssl.cnf 
-gencrl -out intermediate/crl/intermediate.crl.pem

Секция CRL OPTIONS в man ca содержит больше информации о том, как создавать CRL.

Можно проверить содержимое CRL с помощтю утилиты crl.

# openssl crl -in intermediate/crl/intermediate.crl.pem -noout –text

Пока еще не было отозванных сертификатов, поэтому в выводе указано:

No Revoked Certificates.

Необходимо пересоздавать CRL на регулярной основе. По умолчанию, CRL истекает через 30 дней. Это настраивается опцией default_crl_days в секции CA_default.

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

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

Хотя 4096 бит немного больше безопаснее, чем 2048 бит, он замедляет TLS хэндшейки и значительно увеличивает нагрузку на процессор во время хэндшейков. По этой причине, большинство веб-сайтов используют 2048-битные пары ключей.

Если вы создаете криптографическую пару для использования веб-сервером (к примеру, Apache), вам потребуется вводить пароль каждый раз, когда вы перезапускаете веб-сервер. Вы можете указать опцию –aes256 для создания ключа без пароля.

Создание пары ocsp

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

Создадим частный ключ и зашифруем его алгоритмом AES-256.

Создание промежуточного ключа

Создадим промежуточный ключ (intermediate.key.pem). Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем.

# cd /root/ca
# openssl genrsa -aes256 
-out intermediate/private/intermediate.key.pem 4096
Enter pass phrase for intermediate.key.pem: secretpassword
Verifying - Enter pass phrase for intermediate.key.pem: secretpassword
# chmod 400 intermediate/private/intermediate.key.pem

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

Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци (intermediate/openssl.cnf).

# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 
-key intermediate/private/intermediate.key.pem 
-out intermediate/csr/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Intermediate CA
Email Address []:

Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации (/root/ca/openssl.cnf).

# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca 
-days 3650 -notext -md sha256 
-in intermediate/csr/intermediate.csr.pem 
-out intermediate/certs/intermediate.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
Sign the certificate? [y/n]: y
# chmod 444 intermediate/certs/intermediate.cert.pem

Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.

V 250408122707Z 1000 unknown … /CN=Alice Ltd Intermediate CA

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

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

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

Создание электронного адреса

Перед заказом SSL-сертификата нужно создать адрес электронной почты для получения проверочного запроса от Удостоверяющего центра (УЦ). Адрес электронной почты должен принимать одно из следующих значений:

Типы ssl-сертификатов

Существует несколько типов SSL-сертификатов.

Сертификат с проверкой домена (Domain Validation), например, DomainSSL или AlphaSSL. Самый простой и дешевый тип SSL-сертификатов. Подтверждает только домен. Не содержит информации о владельце, поэтому не предназначен для оказания коммерческих услуг на сайте. Физические лица могут использовать только этот тип сертификатов, но он доступен и для юридических лиц.

Сертификат с проверкой домена и организации (Organization Validation), например, OrganizationSSL. Подтверждает не только домен, но и его принадлежность компании. Центр авторизации проверит ее существование, а пользователь сможет увидеть ее название на сайте в информации о сертификате, кликнув на «замок» рядом с адресной строкой браузера.

Сертификат с расширенной проверкой организации (Extended Validation) – например, ExtendedSSL. Считается самым надёжным и предназначен для крупных организаций. При его оформлении центр сертификации проведет расширенную проверку налоговой и коммерческой деятельности компании.

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

При заказе сертификатов Extended Validation или Organization Validation, центр сертификации может запросить следующие виды документов:

• Свидетельство ИНН / КПП;
• Свидетельство ОГРН;
• Приказ о назначении директора;
• Свидетельство о регистрации доменного имени;
• Устав организации (первые 3 и последние 3 страницы);
• Счета на оплату телефонных разговоров с номера компании за последние 3 месяца, с обязательным указанием в счетах названия и номера телефона организации и названия организации-поставщика услуг.

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

Форматы ssl сертификатов

Различные платформы и устройства требуют SSL сертификаты в различных форматах, например, сервер Windows использует PFX файлы в то время как Apache сервер использует индивидуальный PEM (.crt .cer) файлы. Ниже информация о форматах сертификатов и как преобразовать SSL сертификаты из одного формата в другой.

• PEM – популярный среди сертификационных центров, имеют расширение .pem, .crt, .cer, и .key. Файлы закодированы в Base64 и обязательно начинаются со строки “—– BEGIN CERTIFICATE —–“, заканчиваются строкой “—– END CERTIFICATE —–“. Apache и аналогичные серверы используют сертификаты в PEM формате.
• DER – бинарная форма сертификата в формате PEM. Иногда имеет расширение файла .der но чаще .cer. DER обычно используется в платформах Java.
• PKCS # 7 / P7B – файлы PKCS # 7 или P7B закодированные Base64, начинаются со строки “—– BEGIN PKCS7 ——” и заканчиваются строкой “—– END PKCS7 —–“. P7B файлы содержат только сертификат и промежуточные сертификаты, частный ключ используется как отдельный файл. Платформы поддерживающие P7B файлы: Microsoft Windows и Java Tomcat.
• PKCS # 12/PFX – бинарная форма, в одном файле хранится сертификат сервера, промежуточные сертификаты и закрытый ключ. PFX файлы обычно имеют расширения .pfx и .p12. Как правило, используется в Windows для импорта и экспорта сертификатов и закрытых ключей. При конвертации PFX-формата в PEM-формат необходимо открыть файл в текстовом редакторе и скопировать каждый сертификат и закрытый ключ (включая BEGIN / END включение) в свои отдельные текстовые файлы, сохранить их как certificate.cer, CACert.cer, и privateKey.key.

Чем еще отличаются сертификаты между собой

• Скоростью выпуска. Быстрее всего выпускаются сертификаты с валидацией только домена, дольше всего с EV валидацией, от 7 рабочих дней.
• Количество перевыпусков сертификата — у большинства центров сертификации неограниченно. Требуется, если допустили ошибку в данных об организации.
• Гарантия — для некоторых сертификатов есть гарантия от 10.000 $. Это гарантия скорее не для покупателя сертификата, а для посетителя сайта, где установлен сертификат. В случае если посетитель сайта с таким сертификатом пострадает от фрауда и потеряет деньги, то центр сертификации обязуется их ему компенсировать до суммы указанной в гарантии. То есть центр сертификации как бы дает гарантию на свои сертификаты и что их невозможно установить на «левый» домен. На практике такие случае мне не известны поэтому на этот параметр можно не обращать внимание.
• Бесплатный тестовый период — из платных сертификатов есть у symantec secure site, geotrust rapidssl, comodo positive ssl, thawte ssl web server. Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free
• Возврат средств — есть почти у всех сертификатов в течении 30 дней, хотя бывают и сертификаты без периода moneyback

Списки отзывов сертификатов

Списки отзывов сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Клиентское приложение, к примеру, веб-браузер, может использовать CRL для проверки подлинности сервера. Серверные приложения, такие как Apache или OpenVPN, могут использовать CRL для запрета доступа клиентам, которые больше не являются доверенными.

Отзыв сертификата

Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.

Создадим серверный сертификат для тестирования.