Debian.pro

Блог для пользователей и администраторов Debian


Большой мануал: часть 14. Получаем ssl-сертификат. Letsencrypt в массы.

Эта статья — часть Большого Мануала по настройке lamp-сервера на debian.

Предыдущая часть цикла — Ставим и немного настраиваем mysql-сервер (или Percona Server), создаём базы данных.

Следующая часть цикла — Ставим пакеты для lamp+nginx.

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

Впрочем, оно может и к лучшему. За этот год letsencrypt вышел из закрытой беты, починил большинство багов (в частности, теперь его сертификаты валидны в XP), а главное — стал выдавать сертификаты всем желающим. Поэтому самоподписанные сертификаты никому не нужны (по крайней мере, для https).
Но вообще мне тупо лень писать очередную бесполезную статью про openssl + свой СА, поэтому я лучше напишу про letsencrypt.

Для начала о самих сертификатах — letsencrypt выдаёт вполне себе валидные сертификаты на 3 месяца (по крайней мере, я не смог найти живой операционки и браузера, которые не считают их валидными). Само собой, через 3 месяца можно получить новый сертификат. Они подойдут для любого «обычного» сайта (то бишь без аудитории в миллионы пользователей, среди которых обязательно попадутся пользователи win98 и ie5 каких-нибудь). Впрочем, если на https для сайта в рамках Большого Мануала мне в целом начхать (это вам решать, нужен на вашем сайте https, не нужен, а если нужен — то платить ли и сколько платить), но вот все админ-панели за https мы убрать просто обязаны, чтобы не снижать безопасность сервера.
Зачем? Да очень просто, заходя в phpmyadmin по http вы просто дарите свой пароль от mysql (ещё и мускульным рутом, небось, ходите туда?) тому, кто может «прослушивать» ваш траф. Аналогично и с любыми системами мониторинга и прочей фигней. В общем, всё, куда левым людям заходить нельзя, нужно убирать за https, а не только за пароль, иначе пароль этот секретом ни для кого не будет.

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

И да, вы всё ещё можете использовать StartSSL, просто LetsEncrypt показался мне более удобным, по причине существования консольных клиентов.

Теперь немного о том, что мы будем делать и почему так. Ну и немножко советов.
Во-первых, я бы советовал использовать letsencrypt с отдельного сервера для всех своих проектов (то есть делаем виртуалку, со всех своих продакшн-серверов проксируем запросы для LE в неё — когда будем настраивать nginx, я покажу как). Консольный клиент LE в лучших традициях девопсов чекаутится из гита (в принципе, на jessie есть пакет, но он в бэкпортах), запускается от рута, а внутри него болтаётся sh-ник. Но если виртуалка у нас одна — то выбора особого не будет, придется делать всё на ней. В целом, софтина пока не подводила, но чёрт знает, в bumblebee вон тоже rm -rf / случайно закоммитили =)
Во-вторых, я бы не советовал использовать встроенную в клиент фичу под названием «я щас за вас вам настрою Опач». Может быть настроит, может быть нет, а может и всё сломает. В любом случае, у нас наружу будет торчать nginx, а его клиент LE настраивать не умеет (точнее, он притворяется, что умеет) и делает это хреново.
В третьих, я бы не советовал вам использовать фичу с автопродлением по крону. Точнее, вы можете получать новый сертификат по крону, он будет складываться в /etc/letsencrypt и лежать там до тех пор, пока вы за ним не придете. Всё веселье в том, что есть ненулевое количество операционок, которые проверяют валидность сертификата по времени по своему локальному часовому поясу. При этом у сертификата есть два поля про срок действия — «Не ранее» и «Не позднее». Ну и во всех сертификатах в это поле вписано GMT-время выдачи (+3 месяца в случае LE в поле «не позднее»). Таким нехитрым образом, любой свежий сертификат не будет являться валидным для некоторых компов в мире ещё примерно 12 часов (он для них будет «из будущего»). Конечно, всё это патчат в новых версиях операционок и браузеров, но кому какое дело — даже у меня в блог 10% людей всё ещё из-под ХР ходят. Так что сертификат мы будет получать, он будет попадать в /etc/letsencrypt (по крону или нет — неважно), а забирать оттуда мы его будем сами в отдельный файл, в который клиент LE точно не полезет.

Если кому-то весь бред выше мог быть неинтересен, то вот дальше вам придется читать (ну или копипастить, ничего хитрого дальше не будет).

Для начала нам нужно поставить letsencrypt-клиент. Для lenny и squeeze поставить LE уже нельзя, вообще никак. Python древний, а в virtualenv никто не собрал (а мне лень). Для wheezy клиент можно поставить только c сайта (можно и из гита, но это уже для задротов, да), он при этом работает вроде нормально. Для jessie клиент можно поставить пакетом из jessie-backports, можно и с сайта тоже. Если же вы наткнетесь на эту статью году эдак в 2017м летом, то, скорее всего, вам будет достаточно apt-get install letsencrypt.

Ну поехали.
Если вы решили ставить клиент из пакета на jessie, то делаем так:

root@server:~# apt-get install letsencrypt -t jessie-backports

Если решили ставить с сайта (или у вас нет выбора), то:

root@server:~# wget https://dl.eff.org/certbot-auto
root@server:~# chmod +x certbot-auto
root@server:~# mv certbot-auto /usr/bin/letsencrypt

Теперь важное. На текущий момент (ну если вы мануал не по диагонали делаете, а по порядку) у нас не должно быть запущено ничего, из того, что занимает порты 80/443. Если запущено — милости просим в /etc/init.d/{nginx,apache} stop до тех пор, пока вы не прочитаете статью про настройку ssl в nginx (которую я ещё писать не начал, хе).
Но вообще я о том, что сейчас мы используем модуль standalone, который для проверки «владения» доменом запускает свой веб-сервер на портах 80 и 443 и шарит по http(s) файлы, в которые letsencrypt ходит снаружи. Позднее мы будем использовать модуль webroot, который будет эти файлы создавать в определенном каталоге (а нам для запуска клиента LE уже не придется стопать nginx), но это уже после правильной настройки nginx.

В letsencrypt можно заказать один сертификат на несколько доменов (и нужно — сколько бы вы сказок про SNI не прослушали, его поддерживают не все клиенты до сих пор). Единственное условие для получения сертификата — чтобы letsencrypt смог придти по http(s) на все домены, для которых вы запрашиваете сертификат, по определенному uri и получить по этому uri определенный файл. uri и содержимое файла генерятся динамически, если что. Соответственно, чтобы получить сертификат — домен уже должен «смотреть» в искомый сервер.

Нам сейчас нужно получить сертификат на fqdn нашего сервера (либо другой домен, который вы будете использовать для размещения там всяких админских панелей). Для примера я добавлю второй домен (вообще же вы можете указать опцию -d примерно 100 раз, чтобы получить сертификат на сотню доменов).

Поехали. Заказываем сертификат, предварительно освободив порты 80/443:

root@server:~# letsencrypt certonly -n --standalone -d yourfqdn.example.com -d seconddomain.example.com --agree-tos --email blabla@example.com

Если у вас уже настроен nginx (часть 16 Большого Мануала), то нам нужно использовать модуль webroot:

root@server:~# letsencrypt certonly -n --webroot -w /var/www/letsencrypt/ -d yourfqdn.example.com -d seconddomain.example.com --agree-tos --email blabla@example.com

Обе этих команды можно в будущем использовать и для продления сертификатов.

Теперь об опциях:
-n — опция читается как «заткнись и ничего не спрашивай». Если у вас при запуске LE происходит ЁНХ — то уберите эту опцию, клиент начнет задавать вопросы, а не использовать дефолтное поведение.
certonly — собственно, опция «заказываем сертификат»
—standalone — для прохождения проверки клиент запустит собственный web-сервер.
—webroot — для прохождения проверки клиент создаст временные файлы в определенном каталоге.
-w — здесь мы указываем каталог для —webroot
-d — указываем домен, для которого заказываем сертификат. Опцию -d можно указывать несколько раз, чтобы получить сертификат на несколько доменов (проверка будет для всех доменов).
—agree-tos — соглашаемся с tos автоматически (чтобы лишний раз не жать стрелочки перед запуском клиента).
—email — здесь вы указываете (в теории) почту для восстановления своих сертификатов. Только вот восстановление пока не работает =) Так что напишите туда на будущее любой рабочий ящик (можно в любом домене).

Если вы всё сделали верно, то в конце своей работы клиент сообщит нам примерно следующее:

 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/yourfqdn.example.com/fullchain.pem. Your cert
   will expire on 2016-08-22. To obtain a new version of the
   certificate in the future, simply run Certbot again.

Если такой надписи вы не наблюдаете, то уберите опцию -n и запустите клиент снова. Если и так непонятно — то добавьте опцию -v (verbose), чтобы разобраться, где не получается пройти проверку.

Нам осталось подготовить файл с сертификатом в том формате, в котором его сможет использовать nginx и отложить его в «безопасное» (ну чтобы туда клиент letsencrypt не пришел и ничего не сломал) место (место это пока временное):

root@server:~# cat /etc/letsencrypt/live/yourfqdn.example.com/{privkey.pem,fullchain.pem} > /root/cert.pem

Если nginx уже настроен (точнее, настроено то, что описано в части 18 Мануала), то можно сделать сразу так (только не забудьте про то, что использовать сертификат лучше не ранее, чем через 12 часов после его получения, если речь про сайт, куда кто-то ходит):

root@server:~# cat /etc/letsencrypt/live/yourfqdn.example.com/{privkey.pem,fullchain.pem} > /etc/nginx/ssl/cert.pem

Вот и всё. Процедуру повторять раз в ~3 месяца =)

Ну и да, насчет StartSSL — полученный от них сертификат можно использовать ровно так же, только нужно «сварить» его в правильном формате (то есть в один файл положить последовательно приватный ключ, сертификат и цепочку сертификата). Плюс у startssl в том, что за 59USD в год у них можно получать wildcard-сертификаты (в любом количестве). В остальных случаях LE вам будет достаточно.
А насчет китайцев из wosign — нахер их, они же китайцы =)

24.05.2016 byinkvizitor68sl|big-manual

Комментарии (20):

  1. Максим :

    Давно не было статей :) Очень годный мануал, жаль что не полный, пока… Надеюсь в следующем месяце порадуете еще как минимум одной частью.

  2. На самом деле я упился энергетиками и за ночь написал 3 больших статьи и одну из области «просто добавь воды». Эту сверстал, воду завтра опубликую, а на следующей неделе 2 оставшихся доверстаю.

  3. Ну в смысле про LE — одна из четырех ночных.

  4. Давай, возобновляй активность :)

  5. j7sev :

    Касательно последней фразы про WoSign и их CRL/OCSP.
    В Китай ходить не придется, т.к. CRL и OSCP доступны через CDN от Akamai, причем ровно так же поступили и LetsEncrypt. Из нескольких географических точек RTT < 2ms.
    В обоих случаях — очень грамотный ход.

  6. Мда, жизнь течет, жизнь меняется. Поправил статью.

  7. Роман :

    Подскажите как крон задачу настроить что бы процедуру раз в 3 месяца не повторять?

  8. На startssl получить серт =)

    А так — с разницей в сутки раз в 2 месяца запихать в крон 2 команды:
    1) letsencrypt certonly -n —webroot -w /var/www/letsencrypt/ -d yourfqdn.example.com -d seconddomain.example.com —agree-tos —email blabla@example.com
    2) cat /etc/letsencrypt/live/yourfqdn.example.com/{privkey.pem,fullchain.pem} > /etc/nginx/ssl/cert.pem

  9. Роман :

    Спасибо за ответ)))
    https://certbot.eff.org/#debianwheezy-nginx тут описывается не много другой метод получения сертификата только я не могу понять там ни слова нет про то где настроить его в ssl в nginx.
    И там же написано что обновить сертификат командой /path/to/certbot-auto renew —dry-run
    PS. если глупости по написал сильно не смейтесь, я только учусь )))

  10. Роман :

    подскажите использую вот эту команду cat /etc/letsencrypt/live/yourfqdn.example.com/{privkey.pem,fullchain.pem} > /root/cert.pem
    (вторая не срабатывает)
    файл cert.pem получается пустой, и после проверки валидности конфиг-файла, он ругается на cert.pem

  11. Роман :

    вроде разобрался ))) только пришлось вручную данные копировать в cert.pem, сами ни как не хотели записываться, подскажите как исправить это?

  12. > только пришлось вручную данные копировать в cert.pem, сами ни как не хотели записываться, подскажите как исправить это?
    Откуда они сами должны были записываться? И как копировали. Вторая команда из моего прошлого коммента как раз копирует серт в правильное место.

  13. Роман :

    установлена Debian GNU/Linux 7.10 (wheezy)
    При выполнении cat /etc/letsencrypt/live/yourfqdn.example.com/{privkey.pem,fullchain.pem} > /etc/nginx/ssl/cert.pem
    Получается cert.pem 0b (пустой)

  14. Потому что команды копировать бездумно не нужно.

  15. Роман :

    в каком смысле бездумно??? естественно «yourfqdn.example.com» я заменил на мойдомен.ру
    Где я еще не прав?

  16. Файлы-то такие есть?
    ls /etc/letsencrypt/live/yourfqdn.example.com/{privkey.pem,fullchain.pem}

  17. Роман :

    какая то чудесная х..ня сей час все записалось)))
    В пошлый раз пробовал фай создается но в нем ни чего нет, я по другому чуть сделал, у меня панель веста стоит я в ней прописал сертификаты просто и все только там в разные файлы прописываешь.
    Спасибо что Вы в стороне не остаетесь!!! Это редкость сей час на многих форумах!!!

  18. Так это не форум )

  19. mrz :

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

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

    Да.

Написать комментарий