После непродолжительного курения 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 в конфигурационном файле
Для того, чтобы экспортировать данный сертификат в формат 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.
По мотивам статьи добавил себе в .bashrc такое:
check_cert() {
openssl x509 -text -noout -in *.crt | grep -A 1 -E "Alternative|Before|After"
openssl x509 -noout -modulus -in *.crt | openssl md5
openssl rsa -noout -modulus -in *.key | openssl md5
}
Удобненько.
"Данная процедура избавляет от появления предупреждающего сообщения с текстом "Используемый сервер имеет сертификат безопасности, который невозможно проверить" при каждом новом сеансе связи с почтовым сервером:"
Сделал все по статье, сообщение никуда не делось. Почему?
Денис, сервер, на который Вы установили сертификат, публично доступен через Интернет? Если да, дайте адрес, посмотрю.
Нашел почему, в sendmail.cf имя файла было с ошибкой прописано.
Если нужно преобразовать сертификат из формата p12 в pem, то команда следующая:
openssl pkcs12 -in orig.p12 -out new.pem -clcerts -nokeys