Эта статья — часть Большого Мануала по настройке 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, то делаем так:

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

Теперь важное. На текущий момент (ну если вы мануал не по диагонали делаете, а по порядку) у нас не должно быть запущено ничего, из того, что занимает порты 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:

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

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

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

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

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

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

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

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

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