22.04.2018 18:22
Nexon 22 3900 Источник
Как и многие, я давно ждал возможности получения wildcard-сертификатов от Let's Encrypt. И вот момент настал, а мануала на Хабре так и нет. Ну что ж, попробуем исправить это.

Это наиболее упрощенный мануал по настройке wildcard-сертификатов от Let's Encrypt.
Вместо CloudFlare можете использовать другой сервис, т.к. плагины есть в репозитории EPEL.

Установка certbot и плагинов


Нам нет смысла ставить последнюю версию certbot с github, т.к. нужный нам функционал появился еще в версии 0.22.

Для установки certbot и его плагинов нужно подключить репозиторий EPEL.

sudo yum install epel-release -y

После чего запустить установку certbot.

sudo yum install certbot -y

И затем установить CloudFlare плагин для certbot.

sudo yum install python2-cloudflare.noarch python2-certbot-dns-cloudflare.noarch -y

Если вы используете другой сервис, найдите его плагин при помощи yum, например для digitalocean yum list *digitalocean*
Запустите certbot один раз для создания конфигов.

sudo certbot

Настройка CloudFlare API


Для того, чтобы certbot мог автоматом продливать wildcard-сертификаты, нужно указать логин аккаунта CloudFlare и его API Key в конфиге.

Логинимся в свой CloudFlare аккаунт и заходим в профиль


Нажимаем View напротив Global API Key


Вводим пароль от аккаунта, проходим капчу и снова жмем View


Копируем свой API Key


Создаем файл cloudflareapi.cfg в директории /etc/letsencrypt при помощи редактора (например nano):

sudo nano /etc/letsencrypt/cloudflareapi.cfg

И пишем в нём следующее:

dns_cloudflare_email = <ваш CloudFlare логин>
dns_cloudflare_api_key = <ваш CloudFlare API Key>

АХТУНГ! Данный способ хранения API Key небезопасен, но т.к. вы используете Let's Encrypt вам должно быть все равно.

По крайней мере, можете прописать sudo chmod 600 /etc/letsencrypt/cloudflareapi.cfg для ограничения доступа на чтение.

Создание сертификата


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

sudo certbot certonly --cert-name example.org --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflareapi.cfg --server https://acme-v02.api.letsencrypt.org/directory -d "*.example.org" -d example.org

При первом запуске certbot может запросить у вас email-адрес для доставки уведомлений, согласиться с ToS (выбрать A) и одобрить получение спама (выбрать N).
Вот и всё, в случае успеха вы увидите что-то вроде этого
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.org/privkey.pem
   Your cert will expire on 2018-07-21. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le


Нужный вам сертификат fullchain.pem будет находится в директории /etc/letsencrypt/live/example.org.

Настройка веб-сервера


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

Вы сами должны найти настройку SSL для вашей версии веб-сервера и CMS.

Продление сертификата


Все созданные сертификаты продливаются при помощи certbot.

sudo certbot renew

Собственно, открываем /etc/crontab.

sudo nano /etc/crontab

И добавляем строчку.

0 4 * * 2 root certbot renew

Которая означает, что каждый вторник в 4 часа проверять актуальность сертификатов через certbot.

Так же, сюда следует добавить рестарт веб-сервера, который будет использовать данный сертификат, например nginx:

10 4 * * 2 root systemctl restart nginx

Заключение


Настройка простая, но забыть её довольно легко. Поэтому сохраняйте в закладки.

Данный мануал предназначен в первую очередь для энтузиастов под свой сервер или под небольшие проекты, поэтому здесь нет особого внимания к безопасности или дополнительным настройкам.

Комментарии (22)


  1. gudvinr
    22.04.2018 23:19
    #10769140

    Стоит отметить, что certbot хоть и официальный, но непомерно раздутый и на лоукост корыте с 256МБ RAM может просто не запуститься, например.


    acme.sh довольно функциональный и попроще для аудита, чтобы понять, что та версия, что у вас никуда не будет отправлять ключи. И к ресурсом не столь требовательный.


    1. Nexon
      22.04.2018 23:40
      #10769168

      Я не встречал VPS с 256МБ.
      Самая дешевая VPS на том же Hetzner Cloud идет с 2ГБ на борту.


      1. gudvinr
        23.04.2018 02:36
        #10769324

        Мир не ограничен хецнером, линоде и ДО.
        На LowEndBox такого навалом, например.


        1. Nexon
          23.04.2018 07:48
          #10769396
          -1

          Там сайт на WordPress и реселлинг по заявкам. Хорошая шутка, оценил.


  1. ALexhha
    23.04.2018 00:51
    #10769254

    Так же, сюда следует добавить рестарт веб-сервера, который будет использовать данный сертификат, например nginx
    А разве reload будет недостаточно?


    1. Nexon
      23.04.2018 04:44
      #10769346

      Для nginx да.


  1. zar0ku1
    23.04.2018 01:59
    #10769294

    Подскажите, для бесплатного аккаунта на cloudflare годится?


    1. Nexon
      23.04.2018 04:44
      #10769348

      Да.


  1. dragoangel
    23.04.2018 07:18
    #10769380

    Все таки я считаю что верификация через через http безопаснее, так могут и контроль над DNS украсть — этот метод был разработан для дата центров которые предоставляют там всякие cPanel и тд, им он и вправду подходит, а если у вас у самих есть доступ к установке пакетов и их настройке — лучше это делать через http но если кто то настойчиво хочет вот эще hook только для dns.he.net: github.com/angel333/certbot-he-hook


    1. Nexon
      23.04.2018 07:30
      #10769390

      Я уже писал в статье, что мануал не затрагивает безопасность, т.к. это всё таки Let's Encrypt, его вряд ли будут использовать те, кто действительно обеспокоен безопасностью своей организации.
      Тем не менее, CloudFlare API работает через HTTPS.

      The Cloudflare API is a RESTful API based on HTTPS requests and JSON responses.


      1. dragoangel
        24.04.2018 08:56
        #10771658

        я знаю как работают нынешние api, и я не о том что трафик могут перехватить — я о том варианте когда вот предположим у вас найдут уязвимость в вашем сайте, сайт стоит на машине с certbot валидирующий по dns, смогут загрузить php shell и увидят конфиг certbot с ключами от dns api =) тут вы поймете где вы ошиблись, тут нужно трезво понимать что сам вебсервер не должен быть настроен на валидацию сертификатов, нужен отдельный proxy который будет валидировать dns, и делать https offloading — тогда хоть ключи от api даже при взломе сайта останутся в надежном месте. Через ключи api они будут делать с вашим dns все что заходят. По поводу

        т.к. это всё таки Let's Encrypt, его вряд ли будут использовать те, кто действительно обеспокоен безопасностью своей организации
        я с вами в корне не согласен: люди которые не обеспокоены своей безопасность — это те 50% обычного http трафика которые еще не юзают LetsEncrypt и для них нецелесообразно или дорого покупать сертификаты. Я вообще не вижу смысла покупать SSL сертификаты платить за «подтверждение» того что я это я, когда я и так без оплаты могу доказать что я это я. Единственный смысл приобретения сертификатов когда дело заходит не про обычные сертификаты: в случае если вам нужны сертификаты для подписи софта, или с расширенными параметрами такие как у платежных систем, банков и крупных организаций — которые кроме лейблов несут кучу юридической фичи типа «гарантий», «страховок» и прочего.


        1. Nexon
          24.04.2018 09:27
          #10771722

          Если вам загрузят php shell, то последнее о чем стоит беспокоиться это API Key от CloudFlare.
          BTW, я не использую PHP на бекенде.

          Единственный смысл приобретения сертификатов когда дело заходит не про обычные сертификаты: в случае если вам нужны сертификаты для подписи софта, или с расширенными параметрами такие как у платежных систем, банков и крупных организаций — которые кроме лейблов несут кучу юридической фичи типа «гарантий», «страховок» и прочего.

          Мне шифрование вообще не нужно, я его для HTTP2 сделал.


    1. Lynn
      24.04.2018 08:37
      #10771640

      Wildcard нельзя провалидировать по http. Только через DNS-01


      1. dragoangel
        24.04.2018 08:40
        #10771644

        Я знаю что wildcard нельзя делать через http, но в том то и дело что зачем вам wildcard через http? :)


        1. Lynn
          24.04.2018 11:28
          #10772028

          > Все таки я считаю что верификация через через http безопаснее

          А к чему тогда была эта фраза?


  1. vesper-bot
    23.04.2018 08:58
    #10769462

    Помнится, у certbot есть плагин к nginx, который его релоадит автоматом, если certbot renew вернул новый сертификат. Так что если настроить плагин, можно и не делать вторую задачу с nginx reload.


  1. Asten
    23.04.2018 20:05
    #10770982

    не сочтите за рекламу, но я писал про получение wildcard и вроде бы в 1 строку все делается.
    habrahabr.ru/post/352720


    1. Nexon
      23.04.2018 20:32
      #10771036

      Да, я видел. Но статья совсем о другом, да и там ручная валидация.


  1. MikFoxi
    24.04.2018 09:28
    #10771726

    А после установки certbot он сам как в дебиане не прописывается в /etc/cron.d/certbot? В дебиане прописывается и каждый день ломится продлевать сертификаты.


    1. Nexon
      24.04.2018 09:30
      #10771736

      Нет, на CentOS 7 такого не замечено. На их месте правильнее было бы полноценный certbotd.service сделать.


      1. vesper-bot
        24.04.2018 09:58
        #10771790

        certbot это же не служба, незачем ему быть постоянно запущенному, а запускаться раз в сколько-то — для этого как раз и нужен крон.


        1. Nexon
          24.04.2018 10:03
          #10771812

          Не сам certbot, а отдельную службу.