8 декабря 2015 г.

Сегодня в очередной рассылке инетересных статей от Хабрахабра я обнаружил очень инетересный заголовок: «Let's Encrypt выходит в публичную бету: HTTPS всюду, каждому, отныне и навсегда бесплатно». Поспешил перейти и почитать.

И знаете, скажу я вам, штука крутая. В общем, ребята, ни много ни мало, замахнулись на то, чтобы покрыть все сайты своими сертификатами. Мне кажется, что у них есть все шансы на это. В общем, я решил не терять времени и попробовать этот letsencrypt на  зубок. Настройка и прочие подробности под катом.

Итак, проект только перешёл в публичную бету, поэтому ничего особенного я от него не ждал. Как и ожидалось, я столкнулся с некоторыми проблемами по ходу конфигурирования, но смог всё это победить.

В качестве документации использовал следующий ресурс: документация. Там всё достаточно подробно расписано, но много воды.

Вообще, суть данного сервиса заключается в том, что процесс получения и настройки сертификатов автоматизирован и требует минимального вмешательства со стороны пользователя. По расчёту разработчиков вы запускаете исполняемый файл, а она за вас получает сертификаты, сохраняет куда нужно и конфигурирует web-сервер. Поскольку проект пока находится в стадии беты, то не всё ещё работает. Разработчики сервиса планируют для каждой ОС сделать свой установочный пакет, который можно без проблем установить через стандартный менеджер пакетов. Но пока установка сводится к склонированию git-репозитория и установку через него. Конфигурированием web-серверов занимаются отдельные плагины, которые, кстати, можно писать самому, если такая необходимость возникает.

Итак. Начнём с установки.

user@webserver:~$ git clone https://github.com/letsencrypt/letsencrypt
user@webserver:~$ cd letsencrypt
user@webserver:~/letsencrypt$ ./letsencrypt-auto --help

Выполнив эти команды мы должны увидеть процесс скачивания и установки бинарника letsencrypt, а затем список доступных команд. У меня этот процесс прошёл без ошибок, всё нормально склонировалось и установилось.

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

Итак, для генерации сертификатов достаточно запустить команду:

./letsencrypt-auto certonly --manual

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

Во время генерации у меня возникли проблемы с почтовыми записями, поскольку в процессе регистрации сертификатов, видимо, используется почтовые возможности сервиса. Я решил эту проблему просто введя почту в доменном имени, на которое у меня прописаны MX-записи и проблема исчезла. Если у вас нет таковых, то, думаю, придётся вам разбираться самим как это решить.

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

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

server {
        listen 443 ssl; #данная директива server будет отвечать только на подключение через ssl.

        ssl on;
        ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
        ssl_trusted_certificate /etc/letsencrypt/live/example.ru/chain.pem;

        include /etc/nginx/options-ssl-nginx.conf;
        
        ...
}

Файл /etc/nginx/options-ssl-nginx.conf я создал отдельно. Там содержится конфигурация nginx для более тонкой работы SSL. Вот его содержимое:

# ciphers chosen for forward secrecy and compatibility
# http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

# disable SSLv3(enabled by default since nginx 0.8.19) since it's less secure then TLS http://en.wikipedia.org/wiki/Secure_Sockets_Layer#SSL_3.0
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1440m;

# enables server-side protection from BEAST attacks
# http://blog.ivanristic.com/2013/09/is-beast-still-a-threat.html
ssl_prefer_server_ciphers on;

# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
ssl_dhparam /etc/nginx/ssl/dhparam.pem;

# config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
# to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
# WARNING: Don't forget to add the following lines to /etc/nginx/conf.d/mapping.conf:
#     map $upstream_http_strict_transport_security $strict_transport_security {
#         '' max-age=31536000;
#     }
add_header Strict-Transport-Security $strict_transport_security;

add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_session_tickets off;

# Requires nginx >= 1.5.9
# enable ocsp stapling (mechanism by which a site can convey certificate revocation information to visitors in a privacy-preserving, scalable manner)
# http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
resolver 8.8.8.8 valid=300s;
resolver_timeout 300s;

# These are included by letsencrypt to each individual host config
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7

Обратите внимание на комменатрии в последней конфигурационном файле. Перед применением настроек nginx необходимо будет прописать файл /etc/nginx/conf.d/mapping.conf и сгенерировать файл /etc/nginx/ssl/dhparam.pem командой openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

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

Для простоты можно прописать редирект с http на https:

server {
        listen 80;
        server_name www.example.ru example.ru;
        return 301 https://example.ru$request_uri;
}

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

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

Буду следить за развитием проекта и по возможности держать вас в курсе.

Ссылки:

Документация
Сайт проекта
Статья на Хабрахабре

Автор: Артур Минимулин ⚫ 8 декабря 2015 г.Тэги: Linux, Совет, Хостинг, Безопасность, Интернет, Конфигурация