↓Skip to main content
  1. ru Posts/
  2. RuPosts/

About SSL from 2015

·16 mins·
#linux #tool #monitoring #ssl
Author
Ashedow
Table of Contents

SSL сертификаты (~ 2015 year)
#

Что это такое, зачем оно нужно, каким бывает, как установить и все все все.
#

SSL
#

SSL — это сокращение от Secure Socket Layer — это стандартная интернет технология безопасности, которая используется, чтобы обеспечить зашифрованное соединение между веб-сервером (сайтом) и браузером (https протокол). Это безопасное соединение, которое гарантирует, что информация которая передается от вашего браузера на сервер остается приватной; то есть защищенной от хакеров или любого, кто хочет украсть информацию. Один из самых распространенных примеров использования SSL — это защита клиента во время онлайн транзакции (покупки товара, оплаты).

Стоит учитывать, что использование https, за счет шифрования, дешифрования, проверок сертификата отнимает немного больше ресурсов и требует больше времени на соединение, по сравнению с http. Неправильно настроеный - 4 роунд рип правильно - 1 раунтрип в firefox и старая opera Выход - типизация проверок. scsp srrl - проверки на валидность.

Сам по себе SSL сертификат представляет собой цифровую подпись, в которой содержится следующая информация: полное (уникальное) имя владельца сертификата открытый ключ владельца дата выдачи ssl сертификата дата окончания сертификата (может выдаваться как на год, так и на несколько лет) полное (уникальное) имя центра сертификации

SSL - как работает
#

Прежде чем начать работу, пользователю, владедьцу сервера необходимо послать запрос на получение того или иного сертификата в центр сертификации (Certification authority), или же сгенерировать его самостоятельно. Он отправляет запрос, сгенерированый открытый ключ и идентификационную информацию. В ответ пользователь получает сам сертификат, и открытый ключ, подписанный закрытым ключом CA. После получения ответа, пользователь помещает цифровой сертификат в базу сертификатов своего веб-сервера.

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

Механизм выглядит следующим образом:

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

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

SSL и браузеры
#

Для корректной работы к браузеру пользователя так же применяются определенные требования:

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

Причины по которым браузер может посчитать Ваш сертификат недействительным
#

  • Срок действия сертификата CA истек. Обновление сертификатов происходит при обновлении браузера.
  • Ключ шифрования CA был скомпроментирован, а корневой сертификат отозван.
  • В браузере, по каким либо причинам отсутствует информация о CA

SSL - каким бывает
#

SSL сертификаты бывают нескольких типов и видов.

Самоподписной сертификат. Его можно сгенерировать прямо на веб-сервере. Также, во всех самых популярных панелях управления хостингом (Cpanel, ISPmanager, Directadmin) возможность сгенерировать сертификат доступна по умолчанию. Однако у такого сертификата есть и свои минусы. В частости, все браузеры будут выдавать ошибку, с предупреждением, о том, что сайт не проверен.

Существует разделение сертификатов по виду того, что они поддтверждают.

  • Сертификаты, которые подтверждают только доменное имя (Domain Validation — DV).
  • Сертификаты, которые подтверждают домен и организацию (Organization Validation — OV).
  • Сертификаты, с расширенной проверкой (Extendet Validation — EV). Это те самые сертификаты с расширенной проверки и зеленой строкой в браузере, о которых мы говорили выше. Получить их может только юридическое лицо, коммерческая, некоммерческая или государственная организация.

Далее идет разделение сертификатов на те, которые поддтверждают один иимеют ли несколько вышеперечисленных пунктов, поддерживают национальные языки (это, например, кириллические домены), повышенный уровень шифрования и т. п.

Обычные SSL сертификаты.
#

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

SGC сертификаты
#

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

Wildcard сертификаты
#

Нужны в том случае, когда вам кроме основного домена нужно обеспечить шифрование также на всех поддоменах одного домена. Например: есть домен domain.com и вам нужно установить такой же сертификат на support.domain.com, forum.domain.com и billing.domain.com

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

Пригодится, если вы хотите использовать один сертификат для нескольких разных доменов. Например, daomain.com, damama.ru api.ttport.net и т. п. Обычно в такой сертификат входит 5 доменов и их количество можно увеличивать с шагом в 5.

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

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

  • Thawte SSL123 Certificate
  • Thawte SSL Web Server
  • Symantec Secure Site
  • Thawte SGC SuperCerts
  • Thawte SSL Web Server Wildcard
  • Thawte SSL Web Server with EV
  • Symantec Secure Site Pro
  • Symantec Secure Site with EV
  • Symantec Secure Site Pro with EV

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

  • Скоростью выпуска. Быстрее всего выпускаются сертификаты с валидацией только домена, дольше всего с EV валидацией, от 7 рабочих дней. Количество перевыпусков сертификата — у большинства центров сертификации неограниченно. Требуется, если допустили ошибку в данных об организации. При этом перевыпуском, по сути, является заказ нового сертификата. Причем не всегда с возвратом средств.

  • Гарантия — для некоторых сертификатов есть гарантия от 10.000 $. Это гарантия скорее не для покупателя сертификата, а для посетителя сайта, где установлен сертификат. В случае если посетитель сайта с таким сертификатом пострадает от фрауда и потеряет деньги, то центр сертификации обязуется их ему компенсировать до суммы указанной в гарантии. То есть центр сертификации как бы дает гарантию на свои сертификаты и что их невозможно установить на «левый» домен. На практике такие случае мне не известны поэтому на этот параметр можно не обращать внимание.

  • Бесплатный тестовый период — из платных сертификатов есть у symantec secure site, geotrust rapidssl, comodo positive ssl, thawte ssl web server. Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free

  • Возврат средств — есть почти у всех сертификатов в течении 30 дней, хотя бывают и сертификаты без периода moneyback

Немного о CA
#

Как уже говорилось ранее, от “популярности” CA зависит то, насколько большой контингент пользователей, а точнее браузеров, будут принимат Ваш сертификат как доверенный

Центров сертификации существует достаточно много, вот перечень самых популярных:

  • Comodo — работает с 1998 штабквартира в Jersey City, New Jersey, США.
  • Geotrust — основан в 2001, в 2006 продан Verisign, штабквартира Mountain View, California, США
  • Symantec — бывший Verisign в состав которого входит и Geotrust. Купил всех в 2010 году.
  • Thawte — основан в 1995, продан Verisign в 1999.
  • Trustwave — работает с 1995, штабквартира Chicago, Illinois, США.

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

Из ограничений бесплатных сертификатов, обычно:

  • Срок действия (от 3-6 мес. Однако ряд CA предоставляет такие сертификаты сроком до 3 лет)
  • Количество сертификатов выдаваемых на один домен/одно лицо.

Получение SSL сертификата
#

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

Самоподписной сертификат
#

Выпуск сертификата.
#

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

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

    openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500

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

  • reg - запрос на создание сертификата;
  • -new - создание запроса на сертификат;
  • -newkey rsa:1024 - создание нового ключа длинной 1024 бит. Длина ключа может быть любой. Однако здесь необходимо соблюдать баланс между защищенностью и скоростью работы. Чем длиннее ключ - тем дольше будет происходить шифрация и дешифрация при отправлении сообщений между клиентом и сервером
  • -nodes - не шифровать закрытый ключ;
  • -keyout ca.key - сохранить закрытый ключ в файл и именем ca.key. Можно указать название по своему усмотрению, однако для простоты дальнейшей работы рекомендуется указывать что это именно ключ (.key) для определенного сертификата (ca, cert, certificate);
  • -x509 - создание именно самоподписного сертификата;
  • -days 500 - срок действия сертификата. Вместо 500 можно указать иное значение или же вовсе опустить этот ключ. В таком случае сертификат будет бессрочны;

Так же можно указать следующие опции

  • -out /путь/до/сертификата/ca.pem
  • -keyout /путь/до/ключа/ca.key

Генерация представляет собой диалог, где у пользователя выясняются следующие данные:

	Country Name (2 letter code) [AU]:		*В поле Country должен двубуквенный код страны по стандарту ISO 3166-1*
	State or Province Name (full name) [Some-State]:
	Locality Name (eg, city) []:
	Organization Name (eg, company) [Internet Widgits Pty L]:
	Organizational Unit Name (eg, section) []:
	Common Name (e.g. server FQDN or YOUR name) []:
	Email Address []:

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

	openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500 -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/emailAddress=support@site.com -out ca.crt

-subj <...> - данные сертификата вида параметр=значение, которые перечисляются через слеш “/”

После успешной генерации можно переходить к установке сертификата.

Сертификаты от CA
#

Другие сертификаты необходимо получать у центров сертификации. Основные моменты здесь стиледующие:

  • Выбор сертификата.
  • Выбор центра сертификации.

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

Выбор CA повлияет на следующе параметры:

  • Доверие. Будет ли установлен сертификат CA в большинстве браузеров или нет;
  • Стоимость сертификата;
  • Гарантия. Этот пунт скорее для посетителей, так как CA дает гарантии того, что данный сертификат установлен только на тот/те домены, на который/которые он выдан;
  • Тип шифрования md5(уже не используется)/sha1(самый популярный)/sha256(то, что будет использоваться завтра);
  • Какие данные потребуются CA от заказчика для выпуска сертификата;
  • Скорость выпуска;
  • Число перевыпусков сертификата;
  • Наличие или отсутствие тестового периода;
  • Возможность возврата средств и сроки отмены заказанного сертификата.

Запрос на получение и получение самого сертификата
#

Для получения сертификата необходимо сформировать специальный запрс - Certificate Signing Request. В ходе формирования запроса буду заданы несколько вопросов о домене, компании, личности самого получателя, почты, на которую будет выслано поддтверждение на выпуск и сам сертификат.

Сгенерировать запрос можно как самостоятельно, так и через центр сертификации.

После завершения генерации будет создано два ключа - публичный и приватный. Публичный ключ не является секретным и помещается в запрос на выпуск сертификата. Сам запрос выглядит примерно следующим образом:

-----BEGIN CERTIFICATE REQUEST-----
BDBhfbHDDJEOcnjvbubBDHBCCcjbBHBjBhHjkGbhbcueHBDBgddwhBHBDHBedbkc
<...>
HBhb8gy+HnceufHBHb+J+tYGhy==
-----END CERTIFICATE REQUEST-----

Данные запроса, ключа, сертификата можно расшифровать и проверить с помощью специальных декодеров.

Расшифровать запрос можно следующей командой:

	openssl req -noout -text -in cert.csr

Для проверки данных сертификата можно выполнить:

	openssl x509 -noout -text -in cert.crt

Для проверки соответствия ключа и сертификата необходимо сразнить значения вывода команд (должны совпадать):

	openssl x509 -noout -modulus -in cert.crt | openssl md5
	openssl rsa -noout -modulus -in cert.key | openssl md5
Несколько других полезных команд:
#

Создание для SSL-сертификата только ключа:

	openssl req -batch -noout -new -newkey rsa:2048 -nodes -keyout cert.key

Генерация CSR-запроса:

	openssl req -new -key cert.key -out cert.csr

Убрать пароль с ключа:

	openssl rsa -in cert.key -out cert.key

Проверка выдачи https (после установки сертификата):

	openssl s_client -host  ulanovka.ru -port 443

Как измерить производительность сетевого соединения:

	openssl s_time -connect remote.host:443

Установка сертификата на сервер
#

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

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

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

Для начала необходимо определить какой сервис “слушает” 80 порт (данный порт по умолчанию используется протоколом http). Cделать это можно выполнив команду:

	netstat -ntpl | grep :80

Вывод может быть например следующим:

	tcp        0      0 188.120.233.16:80      0.0.0.0:*               LISTEN      731/apache2

На выводе видно, что Apche2 отвечает на http запросы по IP 188.120.233.16. Значит и сертификат необходимо устанавливать на него. В случае если вместо apache2 указан nginx либо другой сервис, то и сертификат, соответственно, устанавливать на него.

Установка сертификата на BitrixVM
#

После получения сертификата у Вас на руках должны быть три файла:

  • Файл ключа, полученый при генерации запрса на сертификат. Private key.
  • Сертификат.
  • Корневой или промежуточный сертификат. Предоставляется компанией, выпускающей Ваш сертификат. Файл скачевается с сайта компании-издателя. Обращаем Ваше внимание, что для разных операционных системы эти файлы различны.

Файлы необходимо скопировать на Вашу виртуальную машину из под пользователя root в каталог /etc/nginx/ssl/

Переходим в каталог:

	cd /etc/nginx/ssl

Затем объединяем файлы сертификата для домена и промежуточного(корневого) сертификата в одим файл с расширением .pem следующей командой:

	cat domen.crt root.crt >> cert_domen.pem

где vash_domen.crt - сертификат выпущенный для Вашего домена, root.crt - корневой сертификат Вашего центра сертификации, cert_domen.pem - конечный файл.

Теперь необходимо прописать в конфигурационном файле nginx /etc/nginx/bx/conf/ssl.conf путь до ключа и созданного .pem файла

ssl_certificate         /etc/nginx/ssl/cert_domen.pem;
ssl_certificate_key     /etc/nginx/ssl/private.key;

где cert.pem - созданный .pem файл, private.key - файл ключа.

Так же необходимо проверить следующие строки:

server {
listen 193.107.238.159:443 default_server ssl;

ssl on; #Включает протокол https для данного сервера
ssl_certificate /etc/nginx/ssl/cert_domen.pem; #Путь до созданного из сертификата для домена и корневого сертификата файл
ssl_certificate_key /etc/nginx/ssl/server.key; #
ssl_protocols TLSv1.1 TLSv1.2;

    proxy_read_timeout 200s;
    access_log off;
    include static.conf;

    location / {
        root              /var/www/web/sites;
        try_files         /$host/ @default_host;
        proxy_pass        http://127.0.0.1:80;
        proxy_redirect    http://127.0.0.1:80/ /;
        }
}

Осталось только перезагрузить nginx:

	service nginx restart

Установка на сервер с Apache2
#

Для установки сертификата на веб сервис Apache2, в общем случае, нужно скопировать уже существующий виртуальный хост для http-соединения, сменить порт с 80 на 443, добавить ряд строк:

	<VirtualHost IPv4 или IPv6 адрес, либо *:443>

		DocumentRoot /var/www/leader_site

		ServerName www.leader_site.com

		SSLEngine on

		SSLCertificateFile /etc/ssl/crt/bazov_cert.crt

		SSLCertificateKeyFile /etc/ssl/crt/private.key

		SSLCertificateChainFile /etc/ssl/crt/promejut_cert.crt

		<...>

	</VirtualHost>

Где:

  • SSLCertificateFile – файл основного сертификата для вашего домена.
  • SSLCertificateKeyFile – файл с ключом, сгенерированный в процессе создания CSR.
  • SSLCertificateChainFile – файл промежуточного сертификата (если он имеется), предоставленный вашим центром сертификации. Если эта директива не работает, попробуйте вместо нее использовать SSLCACertificateFile.

Дальше, сохраняем изменения, тестируем конфигурацию Apache:

	apachectl configtest

В случае успеха перезапускаем сервис Apache:

	apachectl restart

Или пары команд:

	apachectl stop
	apachectl start

Установка на сервер с Nginx
#

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

	cp mail.example.com.key /etc/pki/nginx/private/
	cat mail.example.com.crt sub.class1.server.ca.pem > /etc/pki/nginx/certs/mail.example.com.pem2

В конфигурации для хоста nginx необходимо проверить наличие записей вида:

	server {
		listen 443;
		server_name mail.example.com;
		ssl on;
		ssl_certificate /etc/pki/nginx/certs/mail.example.com.pem;
		ssl_certificate_key /etc/pki/nginx/private/mail.example.com.key;

		ssl_session_timeout 5m;

		ssl_protocols SSLv2 SSLv3 TLSv1;
		ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
		ssl_prefer_server_ciphers on;

	location / {
		root /srv/www/htdocs/;
		index index.html index.htm;
		}
	}

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

2014/03/18 13:36:08 [crit] 18730#0: ngx_slab_alloc() failed: no memory in SSL session shared cache "SSL".

ssl_prefer_server_ciphers on; - говорит о том, что при использовании различных протоколов, серверные шифры были более приоритетны, чем клиентские.

ssl_stapling on; - gозволяет серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей. ЗДесь имеются ввиду ответы о валидности сертификата (при проверке на отозванность). С точки зрения безопасности пользователя не важно, кто передает ответы — веб-сервер или сервер CA — ведь ответ в любом случае подписан и валидность ответа тоже можно проверить, а ответ включает в себя свой срок действия. Для работы этой функции нужно указать DNS-сервер, что и делается директивой resolver.

В Nginx поддержка статических ключей для session tickets добавлена в версиях 1.5.8+. Настройка tls session tickets при работе с несколькими серверами делается следующим образом:

	ssl_session_ticket_key current.key;
	ssl_session_ticket_key prev.key;
	ssl_session_ticket_key prevprev.key;

В данном случае current.key — ключ, который используется в настоящий момент времени. Prev.key — ключ, используемый N часов до начала использования current.key. Prevprev.key — ключ, используемый N часов до начала использования prev.key. Значение N должно быть равно указанному в ssl_session_timeout. Мы рекомендуем исходить из интервала в 28 часов.

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

Далее, так же проверяется корректность командой:

	nginx -t

И перезагружается вебсервер командой

	nginx -s reload

Осуществляется проверка - готово!

Небольшое отступление о протоколах и шифрах и прочих аспектах безопасности
#

Шифры
#

Для подписи сертификата используются криптографические алгоритмы с открытым ключом, чаще всего это RSA, DSA или ECDSA.

Наиболее распространены, в частности из-за массовой поддержки версиями протоколов и ОС, сертификаты с использованием RSA. Его недостаток - размер ключа и зависящая от его длины производительность.

DSA, при прочих равных, быстрее RSA, при этом ECDSA гораздо быстрее классической DSA. Однако, увы но некоторые версии ОС и браузеров данный алгоритм шифрования не поддерживают.

Стойкость наиболее распространенных алгоритмов ЭЦП напрямую зависит от стойкости (безопасности) используемой хэш функции. Основные используемые алгоритмы хеширования:

  • MD5 — сегодня считается небезопасным и не используется;
  • SHA-1 — использовался для подписывания большинства сертификатов до 2014 года, сейчас признан небезопасным;
  • SHA-256 — алгоритм, который уже сегодня пришел на замену SHA-1;
  • SHA-512 — на сегодняшний день используется довольно редко.
Протоколы
#

Ряд протоколов, например SSLv2 и SSLv3 содержат фундаментальные уязвимости. Поэтому, их крайне желательно отключать. Кроме того, сейчас почти все клиенты сейчас имеют поддержку TLS 1.0, TLS 1.1 TLS и 1.2.

В случае, если необходима поддержка клиентов с SSLv3, то в качестве компенсационной меры можно разрешить использовать его только с алгоритмом RC4. Правильная конфигурация для Nginx в части протоколов будет выглядеть так:

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Что касается выбора ciphersuites или наборов шифров и хеш-функций, которые будут использоваться для TLS-соединений, — веб-серверы должны использовать только безопасные шифры. Здесь важно соблюсти баланс между безопасностью, скоростью, производительностью и совместимостью. Например, рекомендуемые компанией Яндекс значения:

	   ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;

Заставляем строго соблюдать эти директивы:

	ssl_prefer_server_ciphers on;
Заголовки
#

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

В целом, все они, по большей части, направлены на пресечение xss атак.

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

	add_header Strict-Transport-Security «max-age=31536000;»;

Если же дополнить строку до:

	add_header Strict-Transport-Security «max-age=31536000; includeSubDomains; preload»;

то данные условия будут применимы ко всем доменам третьего и выше уровня вашего домена.

Следующий заголовок определяет HTTP-заголовки Content-Security-Policy и Content-Security-Policy-Report-Only, которые сообщают браузеру список хостов, с которых он может загружать различные ресурсы:

	add_header Content-Security-Policy-Report-Only «default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report»;

Установка почтового сертификата
#

Postfix
#

У нас уже имеются все 3, не раз упоминаемых ранее файлов. Создадим файл который скушает постфикс:

	cat mail.example.com.key mail.example.com.crt sub.class1.server.ca.pem > mail.example.com.pem

копируем полученный файл куда надо, я свой положил в /etc/pki/postfix/ Конечно же не забиваем выставить владельца и права, так как в файле наш ключ.

в /etc/postfix/main.cf добавляем:

	smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
	smtpd_tls_cert_file = /etc/pki/postfix/mail.example.com.pem # путь к нашему файлу
	smtpd_tls_key_file = /etc/pki/postfix/mail.example.com.pem # путь к нашему файлу
	smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
	smtpd_use_tls = yes

	smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
	smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
	smtpd_tls_security_level = may

	smtpd_tls_received_header = yes
	smtpd_tls_loglevel = 1
	smtpd_tls_auth_only = no
	tls_random_source = dev:/dev/urandom

Что значит каждый параметр и за что он отвечает можно узнать в документации для Postifx

Для проверки корректности можно использовать старый добрый openssl:

	openssl s_client -starttls smtp -showcerts -connect localhost:25

В результате должно вернуться что то вроде:

	SSL handshake has read 4760 bytes and written 354 bytes
	---
	New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
	Server public key is 4096 bit
	Secure Renegotiation IS supported
	Compression: NONE
	Expansion: NONE
	SSL-Session:
	Protocol : TLSv1
	Cipher : DHE-RSA-AES256-SHA
	Session-ID: 418AA0ED7BA85B2B9301FA127D05DCAFABCEDC192101A6E75DD872FA3E528366
	Session-ID-ctx: 
	Master-Key: 498FB41D5810A9768710936351DC92169B6D7DEFAHTEDBDUO60DE9349DA7EB5536F975A8BC4AF190466B637CC129A93E
	Key-Arg : None
	Krb5 Principal: None
	Start Time: 1287331961
	Timeout : 300 (sec)
	Verify return code: 0 (ok)
	---
	250 DSN

в /etc/postfix/master.cf раскомментируем следующие строки:

	smtps inet n - n - - smtpd
    -o smtpd_tls_wrappermode=yes	
    -o smtpd_sasl_auth_enable=yes

Ну и, как водится, перезапускаем постфикс, например:

	 postfix stop && postfix start

или:

	postfix reload

Dovecot
#

У нас по прежнему есть 3 файла. Вновь копируем ключ, создаем сертификат который скушает dovecot:

	cp mail.example.com.key /etc/pki/dovecot/private/
	cat mail.example.com.crt sub.class1.server.ca.pem > /etc/pki/dovecot/certs/mail.example.com.pem

В dovecot.conf прописываем:

	ssl_cert_file = /etc/pki/dovecot/certs/mail.example.com.pem
	ssl_key_file = /etc/pki/dovecot/private/mail.example.com.key

Включаем SSL:

	ssl_listen = *
	ssl = yes

Добавить в список протоколов необходимые:

	protocols = pop3 pop3s imap imaps

Важно! Если необходимо обеспечить IMAP и POP на разных субдоменах например imap.example.com и pop.example.com, то нужно для каждого субдомена подготовить сертификаты и внести следующие изменения в dovecot.conf:

	protocol imap {
		listen = 192.0.2.1:143
		ssl_listen = 192.0.2.1:993
		ssl_cert_file = /etc/pki/dovecot/certs/imap.example.com.pem
		ssl_key_file = /etc/pki/dovecot/private/imap.example.com.key
	}
	protocol pop3 {
		listen = 192.0.2.1:110
		ssl_listen = 192.0.2.1:995
		ssl_cert_file = /etc/pki/dovecot/certs/pop.example.com.pem
		ssl_key_file = /etc/pki/dovecot/private/pop.example.com.key
	}

Перезапускаем сервис и проверяем:

	/etc/init.d/dovecot reload

Замена сертификата
#

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

UPD. Сейчас для этого всего есть LetsEncrypt + Certbot и встроенные на сервися сертификаты. Не парьтесь.

Related

sot tool
·3 mins
#linux #tool #monitoring