SSL - secure sockets layer
Возникла у меня однажды необходимость установить SSL-сертификат на почтовый сервер с dovecot-ом. Так как сервер использовался весьма небольшим кругом лиц, то необходимости иметь настоящий сертификат, удостоверенным признанным центром сертификации, не было. Поэтому для экономии времени и денег было принято решение просто создать самоподписанный SSL-сертификат.
После непродолжительного курения man-ов родилось следующее решение:
openssl req -new -x509 -days 3650 -sha256 -newkey rsa:2048 \
-nodes -keyform PEM -keyout my.domain.key -outform PEM \
-out my.domain.crt -subj '/O=Some Org/CN=mail.my.domain'
O – название организации, CN – название сервера. Должно совпадать с именем хоста. Такой сертификат будет действителен 10 лет с момента создания (параметр -days). Файл my.domain.crt нужно положить в директорию /etc/pki/dovecot/certs, а файл my.domain.key – в директорию /etc/pki/dovecot/private, предварительно переименовав их в dovecot.pem или изменив параметры ssl_cert_file и ssl_key_file в конфигурационном файле /etc/dovecot.conf, чтобы привести их в соответствие реальным именам файлов с ключём с сертификатом.
Для того, чтобы экспортировать данный сертификат в формат PKCS#12, который используется многими приложениями от Microsoft, используется следующая команда:
openssl pkcs12 -export -out dovecot.pfx -in dovecot.pem \
-name "mycert" -inkey ../private/dovecot.pem
В данном случае она запускалась из директории /etc/pki/dovecot/certs.
Затем полученный сертификат в файле dovecot.pfx можно импортировать в храниилище доверенных сертификатов того приложения, которое работает с нашим почтовым сервером. Например, в Outlook Express 6 это делается так:
меню "Сервис" → "Параметры..." → вкладка "Безопасность" → кнопка "Сертификаты..." → вкладка "Доверенные корневые центры сертификации" → кнопка "Импорт...", выбрать найл dovecot.pfx, в окне запроса пароля поля оставить пустыми, далее везде согласиться со значениями по-умолчанию.
Данная процедура избавляет от появления предупреждающего сообщения с текстом "Используемый сервер имеет сертификат безопасности, который невозможно проверить" при каждом новом сеансе связи с почтовым сервером:
Обратная операция (преобразование pfx в pem):
openssl pkcs12 -in dovecot.pfx -out dovecot.pem -nodes
или
openssl pkcs12 -in dovecot.pfx -out dovecot.pem
Во втором случае случае будет запрошен пароль для приватного ключа.
Для проверки конфигурации можно заставить openssl выступить в роли почтового клиента следующим образом:
openssl s_client -connect mail.someorg.net:995
и потом использовать команды протокола POP3 для дальнейшего диалога с сервером.
Если надо получить настоящий сертификат от признанного центра сертификации (Certificate Authority или сокращённо CA), то запрос на подписание сертификата (CSR) создаётся так (нужно будет ввести в диалоговом режиме некоторую информацию об организации, инициирующей такой запрос):
openssl req -new -newkey rsa:2048 -sha256 -nodes -keyout my.domain.key -out my.domain.req
Generating a 2048 bit RSA private key
......................+++
....+++
writing new private key to 'my.domain.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:<b>UA</b>
State or Province Name (full name) []:<b>Kyivska obl.</b>
Locality Name (eg, city) [Default City]:<b>Irpin</b>
Organization Name (eg, company) [Default Company Ltd]:<b>Roga and Kopita</b>
Organizational Unit Name (eg, section) []:<b>It Dpt</b>
Common Name (eg, your name or your server's hostname) []:<b>my.domain</b>
Email Address []:<b>[email protected]</b>
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Здесь введенные оператором данные выделены жирным (чтобы было понятнее).
Если хочется создать CSR без лишних вопросов (чтоб бывает нужно в различных скриптах), то это можно сделать вот так:
openssl req -new -newkey rsa:2048 -sha256 -nodes -keyout my.domain.key -out my.domain.req -subj '/C=US/ST=Florida/L=Miami/O=Cool IT Company/OU=Hosting Team/CN=my.domain/[email protected]/subjectAltName=DNS.1=www.my.domain,DNS.2=anothersubdom.my.domain'
Аббревиатуры означают следующее:
C – Country (страна)
ST – State (штат, кантон область страны и.т.п)
L – Locality (обычно город)
O – Organization (название компании)
OU – Organization Unit (отдел компании)
CN – Common Name (основной домен, который должен покрываться сертификатом)
emailAddress – адрес электронной почты
subjectAltName – альтернативные домены (обычно там сабдомен www, если выпускается multi-domain aka UC-сертификат, то доменов в атрибуте "subjectAltName" может быть больше одного).
В результате в файле my.domain.key появится приватный ключ, а в файле my.domain.req – собственно сам certificate signing request (CSR), который нужно потом будет отправить в CA.
А вот так можно проверить соответствие пары сертификат-ключ:
$ openssl x509 -noout -modulus -in my.domain.crt
Modulus=AF89EDE626F8F022D1E9A8E8C1852AC0DCA471B430737358C31DA85BF5F56BBA0F2E42A77501636E8D508EA0832822DEEEB517121B4E188E60E0E46E36971534696CE75453A23361E8B3EFB2E9B8056E6F2043605B5698D6B4AE172BD48437456C3E076ADCF613D6BB83CA4755D6641C473FBBFD346552AD804436D25673DF7FEE4CF19ABC003A7799A4BAE428A11C4611A5018BBD708AC655D043C36BCEE62F0B1FCFD9A7C2D05A284DA1E9185D8D43641D5AEF855472085DDC30105CE829922E39E2327CE8BC0C216403753303EB7DE4DF97ED1B8BCA0B80FDCD597706299BD0B34E6CCB5C878EC4BB6484F1B4D0D6E16B9FFB6ED2C3327CF7DEE2AA1C5F1F
$ openssl rsa -noout -modulus -in my.domain.key
Modulus=AF89EDE626F8F022D1E9A8E8C1852AC0DCA471B430737358C31DA85BF5F56BBA0F2E42A77501636E8D508EA0832822DEEEB517121B4E188E60E0E46E36971534696CE75453A23361E8B3EFB2E9B8056E6F2043605B5698D6B4AE172BD48437456C3E076ADCF613D6BB83CA4755D6641C473FBBFD346552AD804436D25673DF7FEE4CF19ABC003A7799A4BAE428A11C4611A5018BBD708AC655D043C36BCEE62F0B1FCFD9A7C2D05A284DA1E9185D8D43641D5AEF855472085DDC30105CE829922E39E2327CE8BC0C216403753303EB7DE4DF97ED1B8BCA0B80FDCD597706299BD0B34E6CCB5C878EC4BB6484F1B4D0D6E16B9FFB6ED2C3327CF7DEE2AA1C5F1F
Если вывод обоих команд совпадает, то значит ключ соответствует сертификату (сертификат был сгенерирован на основе этого ключа, а не какого-то другого). Может пригодится, если какой-то нерадивый клиент сам покупал сертификат, а потом прислал черт знает что и сам запутался в этом.
UPDATE от 2014-06-26: По мотивам вышеизложенного и камментов ниже свяал себе такой скриптец, чтобы быстро смотреть инфу по сертификатам:
#!/bin/bash
cert="$1"
if [ -z "$cert" ]; then
echo "Checking for validity intervals for certificates in current dir:"
for c in *.crt ; do
echo "File |$c|:"
openssl x509 -text -noout -in $c | grep -A 1 -E "Alternative|Before|After"
echo "============================================================="
done
echo "Checking for mutual correspondence of keys and certificates in current dir (values whould match):"
for c in `ls *.crt | grep -vE "intermediate|bundle"` ; do
echo "File |$c|"
openssl x509 -noout -modulus -in $c | openssl md5
done
for k in *.key ; do
echo "File |$k|"
openssl rsa -noout -modulus -in $k | openssl md5
done
else
echo "File |$cert|:"
openssl x509 -text -noout -in $cert | grep -A 1 -E "Alternative|Before|After"
fiНу и напоследок плохая новость для тех, кто использовал алгоритм SHA-1 при генерации ключей. Он уже признан устаревшим, недостаточно безопасным и скоро сайты, использующие SHA-1-сертификаты, будут признаны ненадежными. Процесс утери доверия к SHA-1 сертификатам будет происходить через такие этапы:
- ноябрь 2014 – Google Chrome начинает показывать предупреждение для сайтов с SHA-1 SSL сертификатами, срок действия которых заканчивается в 2017 году;
- декабрь 2014 – Google Chrome начинает показывать предупреждение для сайтов с SHA-1 SSL сертификатами, срок действия которых заканчивается после 01.06.2016;
- январь 2015 – Google Chrome начинает показывать предупреждение для сайтов с SHA-1 SSL сертификатами, срок действия которых заканчивается в 2016-м году;
- 1-ое января 2016 – Microsoft прекращает доверять SHA-1 сертификатам для подписи кода (Code Signing), которые не имеют временных меток (timestamp);
- 1-ое января 2017 – Microsoft и Mozilla перестанут доверять любым SHA-1 SSL сертификатам.
Упомянутое предупреждение от Google Chrome версии 41.0.2272.89 по состоянию на 2015-03-16 выглядит так: "The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it." и его можно увидеть если кликнуть по пиктограмме в строке адреса у левого её края.
Кстати, если кому нужен недорогой SSL-сертификат (всего за 14$/год), обращайтесь.
Больше информации о практическом использовании OpenSSL можно найти тут: xgu.ru
Отличный сервис для анализа конфигурации TLS, поиска и устранения проблем: https://www.ssllabs.com/ssltest/analyze.html.
