Думаю, уже все знают что такое Let'sEncrypt и как им пользоваться.Очень удобно иметь бесплатные сертификаты SSL,с помощью которых можно перевести свой Веб сервера на желанный и рекомендуемый всеми протокол HTTPS.Однако это не все возможности,которые предоставляет нам данный сервис.Одна из замечательных возможностей - это использование этих сертификатов для безопасного соединения в почте.Именно об этом я и расскажу.

В данном примере я расскажу как подключить эти сертификаты с уже установленным и настроенным демонам postfix + courier-imap-ssl+courier-pop-ssl.

Настраиваем Postfix:

в /etc/postfix/main.cf указываем пути к нашим файлам

smtpd_tls_cert_file = /etc/letsencrypt/live/www.ваш-домен/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/www.ваш-домен/privkey.pem

перезапускаем /etc/init.d/postfix restart

Проверяем:

openssl s_client -connect ваш-домен:465

должен получиться вывод,где главное для нас в начале (выделено красным):

CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = www.ibs.ua
verify return:1
---
Certificate chain
0 s:/CN=www.ваш-домен
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

Красным выделена цепочка вашего сертификата - то есть ваш домен подписан Let'sencrypt Authority,а затем Let'sencrypt Authority подписано корневым сертификатом DST ROOT CA. Это означает что все отлично.

А теперь настроим courier.Тут будет сложнее,ибо из-за своей "древности" там есть один неудобный для нас момент - курьеру надо что б в одном файл были и сертификаты,и приватный ключ.Читать их отдельно он не умеет.А для нас это означает что после обновления сертификатов надо самостоятельно или отдельным скриптом обновлять и файл сертификата курьера.

Итак,для начала сделаем нужный "контейнер".

cat /etc/letsencrypt/live/www.ваш-домен/fullchain.pem > /etc/courier/cert.pem

cat  /etc/letsencrypt/live/www.ваш-домен/privkey.pem >> /etc/courier/cert.pem

Теперь указываем использовать этот сертификат курьеру:

меняем строку TLS_CERTFILE в /etc/courier/imapd-ssl&pop3d-ssl на /etc/courier/cert.pem

Перезапускаем службы и пробуем:

openssl s_client -connect ваш-домен:995 для РОР

openssl s_client -connect ваш-домен:993 для IMAP

Вывод должен быть как и выше у SMTP.

Вуаля!

Dovecot настраивается вообще легко,и без геммороя с совмещением ключа с сертификатом - там просто в /etc/dovecot/conf.d/10-ssl.conf указываем:

ssl_cert = </etc/letsencrypt/live/www.ваш-домен/fullchain.pem

ssl_key = </etc/letsencrypt/live/www.ваш-домен/privkey.pem

ssl_ca = </etc/letsencrypt/live/www.ваш-домен/chain.pem

 

3 комментария

  1. Добрый день! Подскажите пожалуйста. Как раз несколько дней пытаюсь решить вопрос с Lets encrypt сертификатом. На хостинге hosting.energy при создании сайта dommeb.com.ua подключил бесплатный Lets encrypt из Isp панели. Все было хорошо несколько дней, проходил тесты SSL ssllabs.com/ssltest/analyze.html на А+. Пробовал загрузить с мобильного на Android 2.3.6 с стандартного браузера и Maxton - появлялось только предупреждения о ненадежности сертификата , а дальше можно нажать Продолжить и сайт был доступен.

    Неделю назад заметил, что при загрузке с мобильного и тестов на редиректы (поставил в настройках домена на хостинге редиректы с http-https) происходит добавление в url :443 (название SSL порта). И сайт не доступен при загрузке (надпись ошибки).

    Написал в хостинг, решили в течении нескольких дней вопрос. Написали "Исправили конфигурации Nginx относительно редиректов, в конфиги закралась ошибка (вероятно, из-за панели управления) и было 2 редиректа."

    :443 уже не дописывался с мобильного и при тесте на редиректы.
    Но сайт по прежнему не грузился, как с появлением этих двойных редиректов :443 (ошибка на Android 2.3.6 сайт не доступен при загрузке).

    Посмотрел ssl тест, тоже А+ результат, но появилась ошибка в подпункте Handshake Simulation No SNI 2Android 2.3.7 No SNI 2 Server sent fatal alert: handshake_failure

    Погуглил по этой ошибке:
    Здесь про эту ошибку и решение пишут talk.plesk.com/threads/https-websites-not-loading-in-ie.338346/ Передал всю информацию в тех поддержку хостинга.

    Несколько дней переписывался с хостингом, говорят ничего в конфигурации настроек хостинга не меняли, используют стандартный плагин Lets Encrypt сертификата. И они не гарантируют работу SSL от LetsEncryt на устаревших платформах. Предложили выделенный IP за 1.5$ в месяц.
    Хотя несколько дней назад все работало и правок не было на обеих сайтах (все данные в браузерах очищал). А сам сайт хостинга (тоже на этом сертификате, нормально и сейчас грузится с с мобильного и даже без предупреждения)

    Сайты на виртуальном хостинге, без выделенного IP. Один сайт сделал на Opencart с Lets encrypt сертификатом, все было в порядке. Второй тестовый на WordPress - все было тоже хорошо с android 2.3.6. Собирался переходить на третьем сайте (WordPress) с http на https, и уже первые два нормально не грузятся на Android 2.3.6...
    Хотелось бы чтобы все пользователи могли нормально заходить на сайт (в крайнем случае на старых платформах как Android 2.3.6 чтобы было только предупреждение, которое можно пропустить)
    Подскажите пожалуйста, может вы знаете в чем может быть причина?

    Решил посмотреть платные сертификаты, вроде хороший этот от Comodo namecheap.com/security/ssl-certificates/comodo/positivessl.aspx ,
    может знаете, как он работает на платформе Android? Является ли сертификат Comodo достоверным. Немного запутался с этим




    2



    0
    • Тяжело что то так сказать,без детального анализа.Я посмотрел ваш сайт,там действительно все норм с сертификатами.В старых версиях андроида проблема в том,что не обновляются корневые сертификаты удостоверяющих центров,а значит андроид не может доверять современным сертификатам и будет ругаться на сертификаты сайта.Как по мне,так проще сделать проверку по юзер агенту,и для старых андроидов просто не редиректить на https.Это проще,чем пытаться что то исправить для системы, которая уже давно не обновляется и врят ли поддерживается.
      С сертификатами других удостоверяющих центров типа Комодо и Неймчип скорее всего будет тоже самое,ведь они тоже зависят от свежих корневых сертификатов.




      1



      0

Добавить комментарий

%d такие блоггеры, как: