wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Letsencrypt ubuntu nginx: настройка в Debian и Ubuntu / Хабр

alexxlab
No Comments

Содержание

настройка в Debian и Ubuntu / Хабр

Если вдруг вся эта история прошла мимо вас, Let’s Encrypt — центр сертификации от некоммерческой организации ISRG, существующий при поддержке EFF и многих компаний, взявшей на себя миссию дать людям бесплатные SSL/TLS сертификаты для сайтов и серверов. Сертификаты от Let’s Encrypt уже используются на более чем 10 миллионах доменов.

Кроме очевидной бесплатности у сертификатов от Let’s Encrypt есть особое, отсутствующее у любых других коммерческих сертификационных центров, достоинство: если вы однажды получили сертификат от Let’s Encrypt, то, при прочих равных, это навсегда. Не нужно раз в год-два вручную обновлять сертификаты. Не нужно вообще вспоминать что сертификаты где-то есть. Получил, настроил и забыл!

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

Организации автоматического обновления сертификатов в статье уделено пристальное внимание, с тем чтобы вы могли в полной мере оценить это принципиальное преимущество Let’s Encrypt.

Почему эта статья

На сайте EFF есть краткие инструкции по использованию Certbot, рекомендуемой программы для получения сертификатов, но они скорей рассчитаны на тех, кто заходит на свой сервер по SSH лишь по острой необходимости. Более подробная документация тоже есть, но пока всю ее прочитаешь и найдешь всё то, что действительно нужно знать… К тому же, в ней не рассмотрены некоторые важные стратегические вопросы использования сертификатов.

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

Содержание

Из этой статьи вы узнаете…

  1. Как установить и настроить Certbot для регулярного использования.

  2. Что требуется от nginx и как настроить nginx для получения сертификатов.

  3. Как получать сертификаты и как проверить полученный сертификат.

  4. Как установить сертификат от Let’s Encrypt в nginx.

  5. Как автоматически обновлять сертификаты.

Caveat emptor

Всё знаете про SNI? Читайте сразу про установку.

В инструкциях ниже я исхожу из того что ваши сайты будут использовать SNI. Это расширение протокола TLS позволяет браузерам сообщить желаемое имя сайта до получения и проверки SSL сертификата от сервера. Благодаря SNI вы можете разместить сколько угодно сайтов за HTTPS на одном IP. Но не всё так просто — иначе бы зачем я об этом писал?

Есть ряд старых браузеров в принципе не поддерживающих SNI. В их число входят любые версии IE в уже заброшенном Windows XP, встроенный браузер в Android 2.3 и 2.2 из 2010 года, а также некоторые другие более экзотические браузеры и библиотеки типа Java версии 1.6 и Python до версии 2.7.9.

Если вы всё-таки хотите чтобы ваш сайт открывался в IE в Windows XP, то одним отказом от SNI эта проблема не решается. Нужно специальным образом подбирать шифры, уже отказываясь от forward secrecy и рискуя получить низкую оценку от SSL Labs. Как можно догадаться, этот вопрос заслуживает отдельного обсуждения хотя бы потому что пользователям IE под XP можно посочувствовать — у них уже не открывается половина интернета!

Еще год назад от перехода на SNI вас могла бы удержать ограниченная поддержка этой технологии некоторыми поисковыми ботами типа Bing, но сейчас, с появлением десятков сайтов с бесплатными сертификатами от Cloudflare, что без SNI не открываются, бот Bing (что легко проверить), и боты других основных поисковиков, пришли в согласие с реальностью. Сейчас за это можно не волноваться. Отмечу, что у Googlebot таких проблем не было никогда.

Другим поводом для волнений могут быть различные средства доступа к API вашего сайта. Если у вас давно есть API, то есть небольшой шанс что среди ваших клиентов есть какие-то, использующие устаревшие версии Java или Python. Если у вас таких нет, то не о чем переживать. Если же есть — мои соболезнования.

Почему лучше рассчитывать на SNI?

  1. Это просто. Вам не нужно постоянно держать в голове факты о выданных сертификатах. Для какого домена сертификат был выдан первым. К какому сертификату нужно добавлять еще домены. И так далее… Ни о чем таком со SNI не нужно думать.

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

Например, так можно посмотреть домены в сертификате Тематических Медиа:

true | openssl s_client -showcerts -connect habrahabr.ru:443 2>&1 |
    openssl x509 -text | grep -o 'DNS:[^,]*' | cut -f2 -d:

На момент написания статьи эта команда выведет подробный список всевозможных доменов ТМ:

habrastorage.org
api.geektimes.ru
api.habrahabr.ru
geektimes.ru
habrahabr.ru
id.tmtm.ru
lab.geektimes.ru
m.geektimes.ru
m.habrahabr.ru
special.geektimes.ru
special.habrahabr.ru
www.geektimes.ru
www.habrahabr.ru

Никакой секретности и никаких тайн. Вы этого хотите?

Установка Certbot

Если вы читаете этот текст из будущего, когда Certbot уже есть в Debian stable и Ubuntu без обиняков и оговорок, то всё просто:

apt-get install certbot

Либо используйте aptitude или другой пакетный менеджер вашего дистрибутива.

Установка в Jessie

Если у вас еще в ходу актуальный на конец 2016 года Debian stable «jessie», то всё лишь немного сложнее.

  1. Нужно подключить Debian Backports, добавив строчку в /etc/apt/sources.list:

    deb http://ftp.debian.org/debian/ jessie-backports main contrib non-free

  2. Теперь можно устанавливать с указанием источника:

    apt-get update
apt-get install certbot -t jessie-backports

    (Раздел актуален пока только stretch не стал stable.)

Ubuntu версий ниже 16.10 (yakkety)

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install --upgrade letsencrypt

Дальше везде вместо certbot используйте letsencrypt.

Другой дистрибутив

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

wget -O /usr/local/bin/certbot-auto https://dl.eff.org/certbot-auto
chmod +x /usr/local/bin/certbot-auto
ln -s /usr/local/bin/certbot-auto /usr/local/bin/certbot

Везде ниже вместо команды certbot можно использовать команду certbot-auto.

Certbot и webroot

Мы будем получать сертификаты по методу webroot без перенастройки или остановки веб-сервера, под которым подразумевается nginx. Нам нужен какой-то каталог, в который certbot будет писать свои файлы, и какой должен быть доступен из сети удостоверяющему серверу согласно протокола ACME.

Чтобы не писать каждый раз длинную строку из опций, а еще лучше — не вспоминать о них, запишем основные настройки в файл конфигурации, который certbot ожидает найти в /etc/letsencrypt/cli.ini:

authenticator = webroot
webroot-path = /var/www/html
post-hook = service nginx reload
text = True

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

Также нам нужно мягко перезагрузить nginx (без перерыва в обслуживании) при успешном обновлении сертификатов. Ничего не мешает в этот же момент перезапускать и другие сервисы вроде Postfix, использующие полученные сертификаты. Команды указываются через точку с запятой.

Если точка с запятой вызывает ошибку

Если вы видите такую ошибку:

letsencrypt: error: Unexpected line 14 in /etc/letsencrypt/cli.ini: post-hook = service nginx reload; service postfix reload

То вам нужно обновить python-configargparse. Ошибка была исправлена в 0.11.0.

Что будет делать Certbot

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

/var/www/html/.well-known/acme-challenge/example.html

Эти файлы должны будут быть доступны из сети на целевом домене по крайней мере по HTTP:

http://www.example.com/.well-known/acme-challenge/example.html

Для следующих проверок создадим какой-то такой файл:

mkdir -p /var/www/html/.well-known/acme-challenge
echo Success > /var/www/html/.well-known/acme-challenge/example.html

Регистрация в Let’s Encrypt

Регистрацию нужно сделать только один раз:

certbot register --email [email protected]

Здесь ничего сложного.

Подготовим nginx к получению сертификатов

В общем случае для получения сертификата необходимо во всех блоках server добавить следующий блок до других блоков location:

location /.well-known {
    root /var/www/html;
}

Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл /etc/nginx/acme с содержанием блока выше.

# cat /etc/nginx/acme 
location /.well-known {
    root /var/www/html;
}

Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем:

include acme;

Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию. Подробней об этом ниже.

Перезагрузим nginx и проверим что наш тестовый файл виден:

# service nginx reload
# curl -L http://www.example.com/.well-known/acme-challenge/example.html
Success

После проверки лучше удалить тестовый файл — certbot любит удалять за собой всё лишнее, а такой файл будет мешать и вызывать сообщение об ошибке (Unable to clean up challenge directory).

rm /var/www/html/.well-known/acme-challenge/example.html

Теперь у нас всё готово чтобы получить наш первый сертификат.

О переадресации с кодами 301 и 302

Как было уже сказано, ACME сервер Boulder учитывает переадресацию с кодами 301 и 302. В этом смысле не имеет значения где, в конечном счете, находятся файлы, требуемые для прохождения проверок. Переадресация возможна даже на нестандартные порты, без ограничений по конечному протоколу HTTP или HTTPS. Сами Let’s Encrypt рекомендуют использовать переадресацию для создания единой точки проверки прав на домены.

Если вы можете получить эти файлы с помощью curl с ограничением в десять переадресаций, то и Boulder эти файлы увидит. Не должно быть никаких ограничений по IP адресам.

curl --location --max-redirs 10 http://example.com/.well-known/acme-challenge/example.html

Это удобно если у вас сложная структура переадресаций между разными версиями сайтов. Должно быть достаточно подключить тот блок с location только на основном сайте для получения сертификатов для всех остальных.

$ curl --head --silent --location --max-redirs 10 http://somewhere.example.net/... | grep ^HTTP
HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
HTTP/1.1 200 OK

Проверка всегда начинается с запроса по протоколу HTTP на 80 порту.

Если у вас уже всё зашифровано…

Если у вас уже все сайты работают по HTTPS, то вся схема будет работать если у вас настроен переадресующий сервер на 80 порту, сохраняющий $request_uri в ответе.

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

Пример конфигурации такого переадресующего всё-подряд-на-HTTPS сервера:

server {
    listen server.example.com:80 default_server;

    include acme;

    location / {
        return 301 https://$host$request_uri;
    }
}

Такой конфиг стоит определить в /etc/nginx/conf.d/default.conf, в стороне от конфигов конкретных сайтов.

Сервер запускаем явно на внешнем IP чтобы не перенастраивать Apache на другой порт. Если для вас это не проблема, то указание имени сервера в директиве listen можно пропустить.

Если нужно получить сертификат для домена без сайта…

Типичный пример — сертификат для выделенных под SMTP или IMAP серверов, на которых вообще нет каких-то сайтов. Либо используйте универсальный переадресатор что выше, либо…

server {
    server_name smtp.example.com imap.example.com;
    listen server.example.com:80;

    include acme;

    location / {
        return 404;
    }
}

К сожалению, протокол ACME требует чтобы такой сервер был доступен во время каждой проверки. Это практически эквивалентно постоянной доступности, ввиду требования получения и обновления сертификатов без перезагрузки сервера. Не удаляйте такой конфиг после получения сертификата.

Если у вас только Apache2…

Если у вас Apache2, а перейти на всеми любимый nginx возможности нет, то… Добавьте следующие строчки в /etc/apache2/conf-available/certbot.conf:

Alias /.well-known/ /var/www/html/.well-known/
<Directory /var/www/html/.well-known/>
    Satisfy any
</Directory>

Затем

a2enconf certbot
mkdir -p /var/www/html/.well-known
service apache2 reload

И обязательно проверьте, так:

mkdir -p /var/www/html/.well-known/acme-challenge
echo Success > /var/www/html/.well-known/acme-challenge/example.html
curl -L http://localhost/.well-known/acme-challenge/example.html && 
rm /var/www/html/.well-known/acme-challenge/example.html

Существует много причин почему такая схема может у вас в Apache2 не заработать. Пары экранов текста не хватит чтобы описать их все. Не серчайте — статья про nginx.

Получаем сертификаты

У Let’s Encrypt есть лимиты на количество обращений за сертификатами, потому сначала попробуем получить необходимый сертификат в режиме для тестов:

certbot certonly --dry-run -d example.com -d www.example.com

В конце программа должна отчитаться об успешной работе:

The dry run was successful.

Теперь можно смело получать сертификат уже в самом деле. Не забудьте явно указать все необходимые поддомены, такие как www.

# certbot certonly -d example.com -d www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will
   expire on 2017-04-01. 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"

Ура! С получением сертификата закончено!

Если нужно добавить поддомен или домен в сертификат

Если вы вдруг забыли указать поддомен www, или вам нужно добавить другой домен или поддомен в сертификат (которых может быть до 100 в одном сертификате), то это легко сделать после получения сертификата. Просто запустите команду еще раз, добавив требуемое имя:

certbot certonly -d example.com -d www.example.com -d shop.example.com

Вам будет безальтернативно предложено добавить этот домен в сертификат. Если хочется избежать вопросов, то можно сразу указать одобряющий такое поведение ключ:

certbot certonly --expand -d example.com -d www.example.com -d shop.example.com

Операцию можно повторять.

Проверим полученный сертификат

Убедимся что полученный сертификат — именно тот, что нам нужен:

# openssl x509 -text -in /etc/letsencrypt/live/example.com/cert.pem
Certificate:
    Signature Algorithm: ...
      Validity
        Not Before: Jan  3 06:00:00 2017 GMT
        Not After : Apr  3 06:00:00 2017 GMT
        X509v3 extensions:
            ...
            X509v3 Subject Alternative Name: 
                DNS:example.com, DNS:www.example.com

Или, если подробности вам не нужны:

cat /etc/letsencrypt/live/*/cert.pem | openssl x509 -text | 
        grep -o 'DNS:[^,]*' | cut -f2 -d:

Команда должна вывести список доменов в сертификате.

Установка и использование сертификатов

Certbot не перезаписывает сертификаты, а заменяет их ссылками на самые актуальные варианты сертификатов в определенном каталоге, одноименном с первым доменом сертификата (т.е. CN).

Давайте посмотрим что за файлы у нас есть:

 # find /etc/letsencrypt/live/ -type l
/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/chain.pem
/etc/letsencrypt/live/example.com/privkey.pem
/etc/letsencrypt/live/example.com/cert.pem

С этим знанием мы можем задать настройки SSL для nginx:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

Как видите, cert.pem нигде в конфиге не используется, и это не ошибка. Для nginx он не нужен.

Полный рабочий пример конфига:

server {
    server_name www.example.com;
    listen www.example.com:443 ssl; # default_server;
    # выше можно добавить default_server для клиентов без SNI

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 127.0.0.1 8.8.8.8;

    # исключим возврат на http-версию сайта
    add_header Strict-Transport-Security "max-age=31536000";

    # явно "сломаем" все картинки с http://
    add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";

    # далее всё что вы обычно указываете
    #location / {
    #    proxy_pass ...;
    #}
}

Конфиг для переадресации с голого домена без www:

server {
    server_name example.com;
    listen example.com:443 ssl;
    access_log off;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 127.0.0.1 8.8.8.8;

    add_header Strict-Transport-Security "max-age=31536000";

    expires max;
    return 301 https://www.example.com$request_uri;
}

Подразумевается что вы используете какой-то локальный сервер для кеширования DNS запросов. Если это не так, то 127.0.0.1 в директиве resolver нужно заменить на IP используемого DNS сервера.

Настройки шифров и прочее подобное (ssl_dhparam, ssl_session_cache) лучше держать вне конфигов отдельных серверов.

Perfect Forward Secrecy

Если вы переживаете что Certbot может утащить ключи от вашего сертификата не смотря на открытые исходные коды, а значит, в теории, какие-то злодеи смогут расшифровать весь трафик, то спешу вас успокоить. Если для соединения с вашим сайтом используются шифры из семейств DHE и ECDHE, то утечка ключа не позволит расшифровать трафик. В этих шифрах ключ сертификата используется только для подтверждения подлинности, и не используется в качестве ключа для шифрования. Все современные браузеры поддерживают эти шифры.

Если для ECDHE на эллиптических кривых ничего не нужно делать, то для DHE можно было бы использовать усиленные параметры. Лучше всего будет отключить DHE вообще.

Если по какой-то причине без DHE вы не можете обойтись

Если по какой-то причине без DHE вы не можете обойтись, то сначала создадим параметры:

openssl dhparam -out /etc/ssl/private/dhparam.pem 2048

Потом пропишем в /etc/nginx/conf.d/ssl_dhparam.conf одной строкой:

ssl_dhparam /etc/ssl/private/dhparam.pem;

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

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

Но нет, не спешите искать платежные средства! Как и было обещано в начале статьи, с обновлением сертификатов проблем нет.

Если у вас Debian, то нужно лишь дописать к вызову certbot в /etc/cron.d/certbot ключ --allow-subset-of-names:

# последняя строка в /etc/cron.d/certbot
# было certbot -q renew, а надо
certbot -q renew --allow-subset-of-names

Если у вас Debian и systemd, то посмотрите эти инструкции.

Если у вас не Debian или нет файла, то добавим в crontab от root одну лишь строчку (sudo crontab -e):

42 */12 * * * certbot renew --quiet --allow-subset-of-names

Согласно рекомендаций Let’s Encrypt следует пытаться обновить сертификаты два раза в день. Делать это нужно в случайным образом выбранную минуту того часа, а значит вам нужно заменить 42 в этой строке на другое число в диапазоне между 0 и 59. Либо вы можете поступить так как это делается в /etc/cron.d/certbot.

Как это работает

В этой команде ключ --allow-subset-of-names нужен чтобы Certbot пытался получить сертификаты для частичного набора доменов.

Например, были у вас на сервере были сайты www.example.com и shop.example.com, проходящие под одним сертификатом, но потом вы перенесли shop.example.com на другой сервер. Если такой ключ не указать, то Certbot упадет с ошибкой при попытке подтвердить владение shop.example.com, не получив для вас вообще никакого сертификата. Сертификат истечет и ваш сайт уйдет в оффлайн. С этим ключом вы всё же получите сертификаты хотя бы для частичного набора доменов, оставив ваши сайты в сети.

Вот и всё

Если вам близки по духу tee и sed, то есть гораздо более короткая инструкция по настройке связки Let’s Encrypt и nginx, при условии корректно настроенного hostname. Только копируй команды и вставляй.

Нашли ошибку? Напишите в личку, пожалуйста.

Настройка SSL Let’s Encrypt в Nginx на Ubuntu · Dmitriy Azarov

Файлы импорта

Создами несколько файлов для уменьшия копипасты. Первый файл нужен для проверки letencrypt домена.
Создаем файл /etc/nginx/snippets/letsencrypt.conf содержимым

location ^~ /.well-known/acme-challenge/ {
	default_type "text/plain";
	root /var/www/letsencrypt;
}

И файл общих настроек для ssl /etc/nginx/snippets/ssl.conf

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

ssl_protocols TLSv1.2;
ssl_ciphers EECDH+AESGCM:EECDH+AES;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

Создаем директорию, необходимую для работы letsencrypt

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

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

Так как в самом начале нет сертификата, получать его будем по протоколу http. В уже существующем сайте (или новом) имеем:

server {
	listen 80;
	listen [::]:80 ipv6only=on;
	server_name oxozle.com;

	include /etc/nginx/snippets/letsencrypt.conf;
}

Включаем сайт

ln -s /etc/nginx/sites-available/oxozle.com /etc/nginx/sites-enabled/oxozle.com

И рестартуем nginx

sudo systemctl reload nginx

Certbot

Утилита, для запроса и обновления сертификатов из командной строки.

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install certbot

Запрашиваем сертификат через certbot

certbot certonly --webroot --agree-tos --no-eff-email --email [email protected] -w /var/www/letsencrypt -d oxozle.com

HTTPS

Включаем редирект на http и включаем сам https

server {
        listen 80;
        listen [::]:80 ipv6only=on;
        server_name oxozle.com;

        include /etc/nginx/snippets/letsencrypt.conf;

        return 301 https://$host$request_uri;
}


server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2 ipv6only=on;
        server_name oxozle.com;

        ssl_certificate /etc/letsencrypt/live/oxozle.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/oxozle.com/privkey.pem;
        ssl_trusted_certificate /etc/letsencrypt/live/oxozle.com/fullchain.pem;
        include /etc/nginx/snippets/ssl.conf;
}

И рестартуем nginx

sudo systemctl reload nginx

Автоматическое обновление

Сертификат действует 30 дней, мы будем обновлять его чрез cron.

Включаем:

Создаем файл ~/letsencrypt.sh, который будет исполнятся время от времени

#!/bin/bash
systemctl reload nginx

Делаем его исполняемым

chmod +x ~/letsencrypt.sh

Входим в редактирование cron

Добавляем строку

20 3 * * * certbot renew --noninteractive --renew-hook ~/letsencrypt.sh

Создание SSL-сертификатов для Nginx с Let’s Encrypt под Ubuntu 16.04 – Vscale Community

Некоммерческий удостоверяющий центр Let’s Encrypt, развивающийся под эгидой Linux Foundation — хороший способ получить бесплатный (не самоподписанный!) SSL/TLS-сертификат сроком на три месяца, с возможностью автопродления.

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

Требования:

  • Ubuntu Server 16.04;
  • пользователь с sudo-привилегиями;
  • собственно домен; 
  • DNS-запись A вашего домена должна указывать на IPv4-адрес вашего же сервера в Vscale (необходимо для подтверждения владения; доменом). Это также в силе для поддоменов (вроде www.example.site).

Шаг 1. Установка необходимого ПО

Обновим локальные индексы менеджера пакетов и установим клиент letsencrypt:

$ sudo apt-get update
$ sudo apt-get install letsencrypt -y

Мы пойдём по пути использования Web-root плагина letsencrypt, суть работы которого заключается в том, что он помещает специальный файл в каталог /.well-known (путь указан относительно корня веб-директории), необходимый для валидации вашего домена серверной частью ПО Let’s Encrypt.

Если по какой-либо причине ещё не был установлен веб-сервер Nginx — сделайте это с помощью следующих команд:

$ sudo add-apt-repository ppa:nginx/development
$ sudo apt-get update
$ sudo apt-get install nginx -y

Шаг 2. Подготовка к выпуску сертификата

Откройте конфигурационный файл Nginx:

$ sudo nano /etc/nginx/sites-available/default

внутри серверного блока (server { …) поместите блок location:

        location ~ /.well-known {
                allow all;
        }

выйдите из редактора, сохранив изменения, по нажатию Ctrl+X, y, Enter.

Протестируйте конфигурационный файл Nginx на корректность:

$ sudo nginx -t

Перезапустите Nginx:

$ sudo service nginx reload

Шаг 3. Выпуск сертификата

Запустите клиент letsencrypt с повышением и нужными Вам параметрами (/var/www/html — корень вашей веб-директории (по-умолчанию), example.site — домен):

$ sudo letsencrypt certonly -a webroot --webroot-path=/var/www/html -d example.site -d www.example.site

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

Итак, теперь у вас есть 4 PEM-файла, относящихся к сертификату — можно вывести их имена командой (example.site — ваш домен):

$ sudo ls -l /etc/letsencrypt/live/example.site

Шаг 4. Генерация параметров Диффи-Хеллмана

Для улучшения безопасности — cгенерируем параметры Диффи-Хеллмана и запишем в файл (процесс займёт некоторое время):

$ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Шаг 5. Изменение конфигурации Nginx:

Опять отредактируем конфигурационный файл Nginx:

$ sudo nano /etc/nginx/sites-available/default

Привожу проверенный вариант:

server {
listen 80;
listen [::]:80;
server_name example.site;
# редирект на HTTPS
return 301 https://$server_name$request_uri;
server_tokens off;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.site;
ssl_certificate /etc/letsencrypt/live/example.site/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.site/privkey.pem;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# конфигурация Modern
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;
# HSTS - форсированно устанавливать соединение по HTTPS
add_header Strict-Transport-Security "max-age=15768000";
 # Разрешение прикрепления OCSP-ответов сервером
ssl_stapling on;
 # Разрешение проверки сервером ответов OCSP
ssl_stapling_verify on;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
# Запрещение выдачи версии nginx в HTTP-заголовках
server_tokens off;
location / {
try_files $uri $uri/ =404;
}
# для валидации Let's Encrypt
location ~ /.well-known {
allow all;
}
}

Для более подробного разъяснения SSL-директив в конфигурации Nginx: 

Опыт установки сертификата Let’s Encrypt на Ubuntu и nginx / Тяпк

Let’s Encrypt — некоммерческий центр сертификации, предоставляющий бесплатные криптографические сертификаты X.509 для TLS шифрования (HTTPS). Процесс выдачи сертификатов полностью автоматизирован с помощью клиента Certbot. Сертификаты выдаются на 90 дней, однако процесс выпуска новых сертификатов также автоматизирован.

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

Исходные данные:

  • os: ubuntu 16.04
  • web-server: nginx

Процесс установки

На главной странице проекта Certbot выбираем операционную систему и веб-сервер,

и получаем инструкцию по установке:

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install python-certbot-nginx

У Certbot есть плагины, в том числе для Nginx, которые поддерживается на многих платформах и автоматизирует получение и установку сертификатов:

$ sudo certbot --nginx

И тут начинается магия: запускается интерактивный мастер установки сертификата. Он спрашивает, мы отвечаем.

  • Адрес для отправки электронных писем.
  • Согласие с условиями использования
  • Согласие на получение писем от разработчиков Certbot и Electronic Frontier Foundation (учредитель-партнер Let’s Encrypt)
  • На какой домен необходимо получить сертификат?
  • Нужен редирект с HTTP на HTTPS?

Собственно всё, можно идти проверять сертификат

tyapk@host:~$ sudo certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): [email protected]

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: a

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: y

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: xxxx.ru
2: www.xxxx.ru
3: xxx.icc.ru
4: tyapk.ru
5: www.tyapk.ru
-------------------------------------------------------------------------------

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for xxxx.ru
Waiting for verification...
Cleaning up challenges
Deployed Certificate to VirtualHost /etc/nginx/sites-enabled/xxxx.conf for set(['www.xxxx.ru', 'xxxx.ru'])

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

-------------------------------------------------------------------------------
Congratulations! You have successfully enabled https://xxxx.ru

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=xxxx.ru
-------------------------------------------------------------------------------

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/xxxx.ru/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/xxxx.ru/privkey.pem
   Your cert will expire on 2018-03-24. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - 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

Автоматическое обновление

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

$ sudo certbot renew --dry-run

Более подробную информацию и варианты обновления можно найти в документации.

tyapk@host:~$ sudo certbot renew --dry-run
[sudo] пароль для tyapk:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/xxxx.ru.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for xxxx.ru
Waiting for verification...
Cleaning up challenges

-------------------------------------------------------------------------------
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/xxxx.ru/fullchain.pem
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/xxxx.ru/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
-------------------------------------------------------------------------------

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

Как защитить Nginx с помощью Let’s Encrypt на Ubuntu 16.04/18.04

Let’s Encrypt — центр сертификации, который позволяет бесплатно получить TSL/SSL-сертификат. Благодаря клиенту Certbot, который автоматически выполняет большую часть настроек, выпустить сертификат и настроить HTTPS-протокол можно за несколько простых шагов.

Предварительная подготовка

Вам необходимы:

Этап 1. Установка Certbot

Certbot — клиент для автоматического создания и установки SSL-сертификата. Разработчики постоянно работают над его улучшением. Поэтому Certbot, который имеется в стандартном репозитории Ubuntu, обычно устаревший.


  1. 1.

    Для возможности добавления PPA репозиториев выполните команду:

    sudo apt-get install software-properties-common



  2. 2.

    Добавьте репозиторий Certbot командами:

    sudo add-apt-repository ppa:certbot/certbot



  3. 3.

    Затем обновите информацию в операционной системе:



  4. 4.

    Установите Certbot для Nginx командой:

    sudo apt install python-certbot-nginx


Готово, Certbot установлен.

Этап 2. Настройка Nginx Ubuntu

Certbot автоматический ищет в конфигурационных файлах Nginx блок server, отвечающий за домен, для которого будет установлен SSL-сертификат.

Если вы устанавливали Nginx по инструкции Как установить Linux, Nginx, MySQL, PHP (LEMP) в Ubuntu 16.04/18.04, то вы используете конфигурационный файл по умолчанию для одного домена. Файлы вашего сайта расположены в каталоге /var/www/html, а в конфиге в директиве server_name указан домен, который привязан к серверу.

Проверим настройки конфига:


  1. 1.

    Откройте конфигурационный файл командой:

    sudo nano /etc/nginx/sites-available/default



  2. 2.

    В конфигурационном файле должно быть следующее:

    server {

        listen 80 default_server;

        listen [::]:80 default_server;

        # SSL configuration

        # listen 443 ssl default_server;

        # listen [::]:443 ssl default_server;

        root /var/www/html;

        # Add index.php to the list if you are using PHP

        index index.php index.html index.htm index.nginx-debian.html;

        server_name faq-reg.ru www.faq-reg.ru;

        location / {

                try_files $uri $uri/ =404;

        }

}



  3. 3.

    Убедитесь, что в директиве server_name указан домен с и без www. Если это не так, внесите изменения, сохраните и закройте файл.



  4. 4.

    Затем перезапустите Nginx командой:

    sudo systemctl reload nginx


Готово, вы настроили Nginx.

Этап 3. Разрешение HTTPS-подключения

В инструкции Как установить Linux, Nginx, MySQL, PHP (LEMP) в Ubuntu 16.04/18.04 на втором этапе «Установка Nginx» были произведены настройки firewall. Проверьте, что HTTPS-подключение для сервера доступно, с помощью команды

Вы должны получить примерно следующее содержимое:




Этап 4. Получение SSL-сертификата

Certbot позволяет получить SSL-сертификат, а плагин для Nginx — выполнить автоматическую настройку и перезагрузку конфига, если это необходимо.

Для получения SSL-сертификата выполните команду:

sudo certbot --nginx -d faq-reg.ru -d www.faq-reg.ru

Ключ -d определяет имя домена, для которого выпускается сертификат. Укажите вместо домена faq-reg.ru свой домен, который привязан к серверу.

При первом запуске Certbot система запросит ваш e-mail и соглашение на использование сервиса. Затем будет произведена проверка домена: DNS-серверы домена должны указывать на ваш сервер.




Если проверка прошла успешно, Certbot спросит, как вы хотите настроить конфигурацию HTTPS:

  1. Без редиректа — не вносит никаких изменений в конфигурационный файл.
  2. Редирект — настраивает все редиректы для безопасного доступа по HTTPS. Рекомендуется для новых сайтов.

Выберите подходящий вариант (введите 1 или 2) и нажмите Enter:




После окончания установки SSL-сертификата система выдаст сообщение, что процесс установки прошёл успешно. В сообщении будет указано, где расположены файлы вашего сертификата. Сертификат Let’s Encrypt действителен только 90 дней. Certbot автоматически будет обновлять сертификат. При возникновении ошибки вы получите сообщение на e-mail, который был указан при первом запуске Certbot.

При переходе по вашему домену будет указано, что соединение с сайтом защищено:




Готово, теперь ваш сайт защищён SSL-сертификатом Let’s Encrypt. Настройка была произведена автоматически благодаря Certbot.

Помогла ли вам статья?

2
раза уже
помогла

Как настроить Let’s Encrypt для Nginx на Ubuntu 18.04 (с IPv6, HTTP/2 и A+ SSL рейтингом)

Наличие SSL сертификата на сайте никого не удивляет. Скорее удивит отсутствие «безопасного соединения» на сайте. Если вы ничего не знаете о SSL, сначала читаем статью HTTPS и SSL для SEO. После этого возвращаемся к даной инструкции. Это пошаговое руководство, как настроить Let’s Encrypt для Nginx на Ubuntu 18.04 с разными ништяками.

Виртуальные хосты

Предположим, вы хотите разместить домены first.com и second.com на сервере. Создавайте папки для своих файлов:

mkdir /var/www/first
mkdir /var/www/second

Создаем файл конфигурации /etc/nginx/sites-available/first.conf с текстом:

server {
	listen 80 default_server;
	listen [::]:80 default_server ipv6only=on;

	server_name first.com www.first.com;
	root /var/www/first;

	index index.html;
	location / {
		try_files $uri $uri/ =404;
	}
}

Аналогично создаем файл для второго домена:

server {
	listen 80;
	listen [::]:80;

	server_name second.com www.second.com;
	root /var/www/second;

	index index.html;
	location / {
		try_files $uri $uri/ =404;
	}
}

Обратите внимание, что только первый домен имеет ключевые слова default_server и ipv6only = on в строке listen.

Убираем дефолтные настройки nginx:

sudo rm /etc/nginx/sites-enabled/default
sudo ln -s /etc/nginx/sites-available/first.conf /etc/nginx/sites-enabled/first.conf
sudo ln -s /etc/nginx/sites-available/second.conf /etc/nginx/sites-enabled/second.conf

sudo nginx -t #проверяет конфигурацию NGINX на наоичие ошибок
sudo systemctl stop nginx #останавливает сервис NGINX
sudo systemctl start nginx #запускает NGINX с новыми настройками

Если нет ошибок и дополнительных уведомлений, значит все прошло хорошо. На всякий случай, проверить статус Nginx можно командой:

sudo systemctl status nginx

В ответ мы должны увидеть что-то похожее:

В результате настройки виртуальных хостов, мы получили:

  • http://first.com и http://www.first.com загружаются с папки /var/www/first
  • http://second.com и http://www.second.comзагружаются с папки /var/www/second
  • https://www.first.com и https://www.second.com еще не работают

Устанавливаем Certbot на NGINX

Certbot — это официальный клиент для Let’s Encrypt, который позволяет запрашивать SSL сертификаты с помощью командной строки. Официальную документацию можно почитать на сайте: https://certbot.eff.org/docs/.

Установка Certbot в Ubuntu:

sudo apt-get update
sudo add-apt-repository ppa:certbot/certbot #добавляем репозиторий
sudo apt-get update
sudo apt-get install -y python-certbot-nginx #устанавливаем Certbot

Далее устанавливаем сертификаты и конвертируем виртуальные хосты в HTTPS:

sudo certbot --nginx

В интерфейсе командной строки нас попросят:

  • ввести адрес электронной почты,
  • подтвердить согласие с Условиями обслуживания,
  • указать домены  для использования HTTPS (он определяет список, используя строки server_name в вашей конфигурации Nginx),
  • перенаправить HTTP на HTTPS (рекомендуется).

Здесь настройку можно прекратить, так как мы уже получили SSL сертификаты с рейтингом A. Проверить свой сайт с помощью SSL Labs, можно по ссылке https://www.ssllabs.com/ssltest/analyze.html?d=ДОМЕН.

В результате, мы получаем:

  • http://first.com редиректит на https://first.com
  • http://second.com редиректит на https://second.com
  • http://www.first.com редиректит на https://www.first.com
  • http://www.second.com редиректит на https://www.second.com
  • https://first.com и https://www.first.com загружаются с папки from /var/www/first
  • https://second.com и https://www.first.com загружаются с папки /var/www/second

Автоматическое обновление сертификатов Let’s Encrypt

При правильной установке на предыдущем этапе, для автоматического обновления ничего делать не нужно. Certbot добавил задачу cron для автоматического продления срока действия сертификатов. Проверить это можно командами:

sudo certbot renew --dry-run #проверка продления сертификатов
sudo certbot certificates #проверка существующих сертификатов

Настройка HTTP/2 на NGINX

Особеностиью установки Certbot, в нашем случае, является автоматическое редактирование конфигов. Конфиг first.conf теперь должен выглядеть примерно так:

server {
	server_name first.com www.first.com;
	root /var/www/first.com;

	index index.html;
	location / {
		try_files $uri $uri/ =404;
	}

	listen [::]:443 ssl ipv6only=on; # managed by Certbot
	listen 443 ssl; # managed by Certbot
	ssl_certificate /etc/letsencrypt/live/first.com/fullchain.pem; # managed by Certbot
	ssl_certificate_key /etc/letsencrypt/live/first.com/privkey.pem; # managed by Certbot
	include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
	ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
	if ($host = www.first.com) {
		return 301 https://$host$request_uri;
	} # managed by Certbot

	if ($host = first.com) {
		return 301 https://$host$request_uri;
	} # managed by Certbot

	listen 80 default_server;
	listen [::]:80 default_server;

	server_name first.com www.first.com;
	return 404; # managed by Certbot
}

Certbot не добавлял поддержку HTTP / 2, когда он создавал новые серверные блоки, поэтому замените эти строки:

listen [::]:443 ssl ipv6only=on;
listen 443 ssl;

на эти:

listen [::]:443 ssl http2 ipv6only=on;
listen 443 ssl http2;
gzip off;

Рейтинг А+ для SSL сертификатов

В NGINX конфигах наших сайтов содержатся следующие строки:

ssl_certificate /etc/letsencrypt/live/YOUR-DOMAIN/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/YOUR-DOMAIN/privkey.pem;

Более сильные настройки используют OCSP Stapling (сшивание OCSP), поэтому каждому виртуальному хосту будет нужен ssl_trusted_certificate.

Добавьте эту строку (используя имя папки, которую Certbot создал для вашего домена) после строки ssl_certificate_key:

ssl_trusted_certificate /etc/letsencrypt/live/YOUR-DOMAIN/chain.pem;

Теперь давайте отредактируем общие настройки SSL в /etc/letsencrypt/options-ssl-nginx.conf. Скорее всего, они выглядит так:

ssl_session_cache shared:le_nginx_SSL:1m;
ssl_session_timeout 1440m;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS";

Заменяем содержимое файла на:

ssl_session_cache shared:le_nginx_SSL:1m;
ssl_session_timeout 1d;
ssl_session_tickets off;

ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload;";
add_header Content-Security-Policy "default-src 'none'; frame-ancestors 'none'; script-src 'self'; img-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self';";
add_header Referrer-Policy "no-referrer, strict-origin-when-cross-origin";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

Теперь перезапустите Nginx и снова проверяем домен с помощью SSL Labs. Должен получиться рейтинг А+. О том, почему я больше люблю Nginx, а не Apache, читаем тут: NGINX или Apache?

Подробная инструкция по установке SSL-сертификата Let’s Encrypt на сервер с CMS Bitrix и Nginx

Да, на Хабре уже много текстов про сертификаты Let’s Encrypt, но полной пошаговой инструкции я, к сожалению, не нашёл. Хотел восполнить пробел. К тому же, с мая 2016 года в процессе установки произошли незначительные изменения, которые могут сбить с толку новичка. Поэтому я решил написать эту инструкцию. Так сказать себе на память и другим в помощь.

Эта инструкция, в первую очередь, должна быть интересна новичкам.


Если у вас все настройки установлены по умолчанию, можно смотреть те пути, которые я привёл. То есть, если вы используете систему, установленную с помощью скрипта Bitrix environment на операционной системе CentOS 6.X. Если же нет, вы и сами знаете где что лежит.

Установка

Первое, что необходимо сделать — установить git:

# yum install git

Далее переходим в директорию /tmp:

# cd /tmp

С помощью git скачиваем файлы Let’s Encrypt. Сам скрипт теперь называется certbot:

# git clone https://github.com/certbot/certbot

Переходим в скачанную директорию:

# cd certbot

На всякий случай, даем права на выполнение для файла скрипта:

# chmod a+x ./certbot-auto

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

Далее следует команда непосредственно получения сертификата:

# ./certbot-auto certonly --webroot --agree-tos --email [email protected] -w /home/bitrix/www/ -d my-domain.ru -d www.my-domain.ru

—webroot — так как автоматическая установка для nginx пока не надежна, используем этот ключ;
—agree-tos — соглашаемся с лицензионным соглашением;
—email [email protected] — указываем свой e-mail. В дальнейшем он может пригодиться для восстановления своего аккаунта;
-w /home/bitrix/www — указываем корневую директорию сайта;
-d my-domain.ru — наш домен. так же можно указывать и поддомены, например -d site.my-domain.ru.

После этого скрипт начнет работу и предложит установить недостающие пакеты. Соглашаемся и ждём.

Если всё завершится успешно, вы увидите сообщение:

IMPORTANT NOTES:

- Congratulations! Your certificate and chain have been saved at

/etc/letsencrypt/live/my-domain.ru/fullchain.pem. Your

cert will expire on 2016-08-21. To obtain a new version of the

certificate in the future, simply run Certbot again.

- If you lose your account credentials, you can recover through

e-mails sent to [email protected].

- Your account credentials have been saved in your Certbot

configuration directory at /etc/letsencrypt. You should make a

secure backup of this folder now. This configuration directory will

also contain certificates and private keys obtained by Certbot so

making regular backups of this folder is ideal.

- 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

Сертификаты установлены, осталось только указать nginx’у, где они лежат.

Настройка

Открываем конфигурационный файл ssl.conf:

# vim /etc/nginx/bx/conf/ssl.conf

Если у вас уже были установлены сертификаты, удаляем или комментируем строки с ними и вставляем новые:

ssl_certificate /etc/letsencrypt/live/my-domain.ru/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/my-domain.ru/privkey.pem;


Не забываем включить ssl, если этого не было сделано ранее:

ssl on;

keepalive_timeout 70;

keepalive_requests 150;

ssl_session_cache shared:SSL:10m;

ssl_session_timeout 10m;


После этого перезапускаем nginx:

# service nginx reload

Если он не выдал никаких ошибок, значит всё в порядке. Можно зайти на сайт и посмотреть что получилось.

Обновление

Сертификат выдается на 90 дней, так что после этого срока нужно будет его обновить. Делается это командой:

# certbot-auto renew

Её так же можно поставить в cron.

На этом всё. Для составления инструкции я использовал статью Yet another инструкция по получению ssl-сертификата Let’s Encrypt и официальный гайд.

Использование Let’s Encrypt с NGINX в Ubuntu 18.04

Обзор

С запуском Let’s Encrypt открылся совершенно новый мир для тех, кто хотел защитить свои веб-сайты легко и без огромных затрат. Типичный сертификат до Let’s Encrypt запускал операторы веб-сайтов несколько сотен в год. В этом руководстве вы узнаете, как запрашивать бесплатные сертификаты и автоматизировать процесс обновления с помощью Let’s Encrypt с NGINX.

Let’s Encrypt предоставляет инструмент под названием Certbot, цель которого — упростить управление сертификатами, а также помочь автоматизировать этот процесс.Certbot находится в PPA, поддерживаемом Let’s Encrypt, который вам нужно будет установить.

Установка PPA

Let’s Encrypt поддерживает Ubuntu PPA, который предоставляет пакеты для упрощения управления сертификатами. Основной инструмент certbot предназначен для автоматизации настройки Apache и Nginx, а также для управления сертификатами, которые были запрошены.

Чтобы добавить Let’s Encrypt PPA в Ubuntu, выполните следующие команды.

 sudo apt-get update
sudo apt-get установить общие свойства программного обеспечения
sudo add-apt-репозиторий вселенная
sudo add-apt-репозиторий ppa: certbot / certbot

Чтобы установить Certbot и плагин Nginx, выполните следующую команду.

 sudo apt-get установить certbot python-certbot-nginx

Настройка NGINX и запрос сертификатов

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

Запустите команду certbot с флагом –nginx.

 судо certbot --nginx

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

 Сохранение журнала отладки в /var/log/letsencrypt/letsencrypt.log
 Выбранные плагины: Authenticator nginx, Installer nginx
 В ваших файлах конфигурации имена не найдены. Пожалуйста, введите свой домен
 имя (а) (через запятую и / или пробел) (для отмены введите 'c'):

Имя (а) хоста должно быть зарегистрировано в DNS и разрешаться. IP-адрес, возвращаемый DNS, также должен совпадать с локальным IP-адресом сервера.Certbot проверит это при запросе вашего сертификата.

 Получение нового сертификата
 Выполнение следующих задач:
 http-01 вызов для blog2.rigpig.ca
 Ожидание подтверждения…
 Устранение проблем
 Развертывание сертификата на VirtualHost / etc / nginx / sites-enabled / default

Если запросы выполнены успешно, вам будет предложено указать, должен ли Certbot автоматически обновлять NGINX или нет. Как упоминалось ранее, конфигурация применяется к сайту по умолчанию. Любые пользовательские сайты необходимо будет настроить вручную.

 Выберите, следует ли перенаправлять HTTP-трафик на HTTPS, удаляя HTTP-доступ.
 
 1: Без перенаправления - больше не вносите изменений в конфигурацию веб-сервера.
 2: Перенаправление - сделайте все запросы перенаправленными для безопасного доступа HTTPS. Выберите это для
 новые сайты, или если вы уверены, что ваш сайт работает по HTTPS. Вы можете отменить это
 изменить, отредактировав конфигурацию вашего веб-сервера.
 
 Выберите соответствующий номер [1-2], затем [введите] (нажмите 'c' для отмены): 2

Теперь ваш сертификат установлен, и, если вы выбрали автоматическую конфигурацию NGINX, ваш сервер готов поддерживать TLS.

 Поздравление

.

Как установить Let’s Encrypt с Nginx в Ubuntu 16.04 и Ubuntu 18.04

Это пошаговая инструкция по установке Let’s Encrypt SSL с NginX на Ubuntu 16.04 или Ubuntu 18.04 (оба являются популярными версиями LTS). Я постараюсь описать несколько полезных настроек, которые сделают настройку простой и умной. Я буду использовать разные команды, которые будут выполняться из-за различий в версиях Ubuntu. Эти блоки будут выделены, поэтому обратите на это внимание, но почти все должно быть таким же.

Требования:

Вам понадобится сервер Ubuntu 16.04 или Ubuntu 18.04 с доступом SSH, зарегистрированное доменное имя, указывающее на IP-адрес вашего сервера, и небольшая часть знаний о том, как использовать консоль Linux и выполнять команды на сервере Ubuntu. Вся установка займет около 30 минут.

Шаг 1. Установите LetsEncrypt

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

sudo apt-get update

Добавить репозиторий программного обеспечения Ubuntu 16.04 
  sudo apt-get install software-properties-common python-software-properties
sudo add-apt-репозиторий ppa: certbot / certbot
sudo apt-get update
Добавить репозиторий программного обеспечения Ubuntu 18.04 
  sudo apt-get install software-properties-common
sudo add-apt-репозиторий ppa: certbot / certbot
sudo apt-get update

Установка

На данный момент все готово для установки LetsEncrypt на ваш сервер:

sudo apt-get install letsencrypt

Эта команда установит фиктивный пакет letsencrypt, который включает certbot и другие утилиты для установки SSL .

Шаг 2. Настройте NginX для шифрования SSL

В моих примерах конфигурации я буду использовать доменное имя ssl.itsyndicate.org . Не забудьте изменить его под свои нужды, когда будете делать копипаст. Пришло время сделать небольшой лайфхак, который покажет вам, как оптимизировать процесс добавления новых сертификатов на ваш сервер. Мы будем использовать конфигурацию по умолчанию NginX для перехвата всех запросов с незащищенным соединением, которые идут на наш сервер, не-ssl, который будет нацелен на порт 80.

  сервер {
    слушаем 80 default_server;
    имя сервера _;

    location ~ /\.well-known/acme-challenge/ {
        позволять все;
        корень / вар / www / letsencrypt;
        try_files $ uri = 404;
        сломать;
    }
}

Как видите, мы используем каталог /\.well-known/acme-challenge/ для перехвата всех запросов о местоположении и каталог / var / www / letsencrypt для размещения acme-проблем. Итак, давайте создадим каталог после того, как вы отредактировали конфигурацию vhost NginX по умолчанию:

  судо mkdir -p / var / www / letsencrypt

Перед применением изменений в настройках NginX всегда проверяйте файл конфигурации:

  Судо Nginx -t

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

  nginx: файл конфигурации / etc / nginx / nginx.conf синтаксис в порядке
nginx: файл конфигурации /etc/nginx/nginx.conf, тест прошел успешно

Чтобы применить изменения к нашей новой конфигурации виртуального хоста NginX, которая предназначена для перехвата всех проблем с сертификатами Let’s Encrypt , выполните следующие действия:

sudo service nginx перезагрузить

Шаг 3. Запросите новый Let’s Encrypt SSL

Пришло время запросить наш первый SSL-сертификат Let’s Encrypt для нашего домена:

  sudo letsencrypt certonly -a webroot --webroot-path = / var / www / letsencrypt -m mail @ example.com --agree-tos -d ssl.itsyndicate.org

Позвольте мне описать некоторые важные параметры в нашей команде:

--webroot-path = / var / www / letsencrypt — здесь мы настраиваем каталог, в котором будут храниться все запросы. Мы настроили NginX для обслуживания этого каталога.

-m [email protected] — с помощью этой опции вы настраиваете свой адрес электронной почты

--agree-tos — эта опция нужна не для подготовки TOS, а для их принятия.Это своего рода полностью автоматизированный способ установки Let’s Encrypt SSL

-d ssl.itsyndicate.org — этот параметр используется для выдачи SSL для желаемого домена

После выполнения команды вы должны увидеть сообщение с поздравлением:

  ВАЖНЫЕ ПРИМЕЧАНИЯ:
- Если вы потеряете учетные данные, вы можете восстановить их через
электронные письма, отправленные на [email protected].
- Поздравляю! Ваш сертификат и цепочка сохранены в
/etc/letsencrypt/live/ssl.itsyndicate.org/fullchain.пем. Ваш сертификат
истекает 2018-08-01. Чтобы получить новую версию
сертификат в будущем, просто запустите Let's Encrypt еще раз.
- Учетные данные вашей учетной записи были сохранены в вашем Let's Encrypt
каталог конфигурации в / etc / letsencrypt. Вы должны сделать
безопасное резервное копирование этой папки сейчас. Этот каталог конфигурации будет
также содержат сертификаты и закрытые ключи, полученные Let's
Зашифруйте, поэтому делать регулярные резервные копии этой папки идеально.
- Если вам нравится Let's Encrypt, рассмотрите возможность поддержки нашей работы:

Пожертвование ISRG / Let's Encrypt: https: // letsencrypt.орг / пожертвовать
Пожертвование в EFF: https://eff.org/donate-le

Шаг 4. Настройка NginX vhost

Теперь у нас установлен новый SSL на /etc/letsencrypt/live/ssl.itsyndicate.org/ . Пришло время настроить наш виртуальный хост NginX для обслуживания https запросов для желаемого домена. Вот мой пример:

  сервер {
    имя_сервера itsyndicate.org;
    слушайте 443 ssl;

    ssl включен;
    ssl_certificate /etc/letsencrypt/live/ssl.itsyndicate.org / fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ssl.itsyndicate.org/privkey.pem;

    корень / var / www / html /;
    index index.php index.html index.htm;

    location ~ /.well-known {
        корень / вар / www / letsencrypt;
        позволять все;
    }
}

Давайте протестируем и перезагрузим нашу новую конфигурацию NginX:

  судо nginx -t
sudo service nginx перезагрузить

Шаг 5. Настройка автоматического продления SSL-шифрования Let’s Encrypt

Let’s Encrypt выдает сертификаты на 90 дней.У вас есть возможность переустановить его вручную, когда вы получите электронное письмо о том, что ваш SSL скоро истечет, но я думаю, что есть разумный способ автоматизировать это. Мы будем использовать ежедневный cron на нашем сервере Ubuntu для обновления нашего сертификата SSL. Из-за различной версии пакета letsencrypt в Ubuntu 16.04 и Ubuntu 18.04 я буду использовать разные команды обновления .

Обновление Ubuntu 16.04 Let’s Encrypt

Я использую файл /etc/cron.daily/letsencrypt для установки cron со следующим содержимым:

  #! / Bin / bash
/ usr / bin / letsencrypt обновить && / etc / init.перезагрузка d / nginx
Обновление Ubuntu 18.04 Let’s Encrypt

Я использую тот же файл « /etc/cron.daily/letsencrypt », но с другим содержанием:

  #! / Bin / bash
/ usr / bin / letsencrypt Renew --renew-hook "/etc/init.d/nginx reload"

Шаг 6 — Проверка конфигурации SSL

Когда мы закончили настройку, пришло время

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

.

  curl -vI https: // ssl.itsyndicate.org

* Сертификат сервера:
* тема: CN = ssl.itsyndicate.org
* Дата начала: 3 мая, 15:44:12 2018 г ..
* Дата истечения: 1 августа 15:44:12 2018 по Гринвичу
* subjectAltName: хост "ssl.itsyndicate.org" соответствует сертификату "ssl.itsyndicate.org"
* эмитент: C = US; O = Давайте зашифровать; CN = Let's Encrypt Authority X3
* Подтвердите сертификат SSL в порядке.

Второй вариант — открыть свой сайт в Google Chrome и проверить сертификат SSL в инструменте разработки на вкладке безопасности:

Заключение

Теперь вы знаете, как установить Let’s Encrypt SSL на Ubuntu 16.04 или Ubuntu 18.04 для защиты вашего сайта. Это очень простое, полезное и дешевое решение для защиты вашего сайта и улучшения вашего SEO-рейтинга. Комментарии, улучшения и критика всегда приветствуются!

.

Настройка SSL с Lets Encrypt на Ubuntu и Nginx

Let’s Encrypt недавно вышла на публичную бета-версию. Что такое Let’s Encrypt?

Let’s Encrypt — это бесплатный, автоматизированный и открытый центр сертификации (ЦС), работающий на благо общества. Let’s Encrypt — это услуга, предоставляемая исследовательской группой Internet Security Research Group (ISRG).

Итак, в основном бесплатный https. Ура! 🙌

Вот как настроить его на Nginx.

Клонировать репозиторий 

  git clone https: // github.com / letsencrypt / letsencrypt
cd letsencrypt

Если у вас не установлен git , получите его с помощью apt-get .

Получить сертификат

Остановить Nginx 
  sudo service nginx stop
Запустить автоконфигурацию вручную

Утилита автоматической настройки для Nginx еще не настроена (но должна быть скоро!), Поэтому вы не можете просто запустить letsencrypt-auto , что немного облом, но на самом деле текущие шаги не очень жесткий.Запустите это:

  ./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory auth

Это запускает симпатичный интерфейс, который предлагает вам прочитать условия и прочий обязательный мусор. Примите это и введите свой домен (-а), когда он вам скажет. Укажите с и без www , если хотите.

После завершения он сообщит вам, где хранятся ваши сертификаты, что должно быть:

  / etc / letsencrypt / live / www.yourdomain.com/

В этом каталоге должно находиться несколько файлов, два из которых важны: fullchain.pem и privkey.pem , которые будут использоваться ниже.

Настроить сертификаты в Nginx

Теперь отредактируйте конфигурацию nginx, чтобы указать ему использовать SSL и указать, где находятся сертификаты. Ваша конфигурация nginx должна быть либо в /etc/nginx/nginx.conf , либо во внешнем файле в / etc / nginx / sites-enabled / . Мой был на сайтах с поддержкой в файле с именем ghost (e.г. / etc / nginx / sites-enabled / ghost ).

Скажите ему использовать порт 443

В блоке сервера для вашего сайта настройте его на прослушивание порта 443:

  сервер {
    слушать 443 default_server; # Используется как порт 80
    слушать [::]: 443 default_server ipv6only = on;

    #другие вещи
}

Привязка ipv6 не является обязательной.

Включите SSL

Включите SSL и сообщите ему, где находятся ваши сертификаты. Поместите это в любое место в блоке server :

  сервер {
    слушать 443 default_server;
    слушать [::]: 443 default_server ipv6only = on;

    ssl включен;
    ssl_certificate / etc / letsencrypt / live / www.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.yourdomain.com/privkey.pem;

    #другие вещи
}
Настроить редирект с 80 на 443

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

  сервер {
    # ваш существующий блок сервера
}

server {
    слушать 80;
    server_name yourdomain.(. *) $ https: //yourdomain.com$1 постоянно;
    }
}

Сохраните файл и выйдите.

Проверить конфигурацию

Если вы не уверены на 100% в своих способностях набора текста (а я никогда не уверен), лучше всего выполнить следующую команду, которая сообщает Nginx о необходимости загрузить конфигурацию и проверить ее, чтобы убедиться, что она действительна. Если это не так, он скажет вам, почему:

  nginx -c /etc/nginx/nginx.conf -t

У меня пропал ; , так что это избавило меня от проблем на 37 секунд.

Перезагрузите Nginx 

  sudo service nginx start

Протестируйте свой сайт

Перейдите на https://yourdomain.com и наслаждайтесь новой безопасностью.

Вопросы?

Оставьте комментарий!

.Руководство пользователя

— документация Certbot 1.8.0.dev0

Certbot использует несколько различных команд (также упоминаемых
как «подкоманды») для запроса определенных действий, таких как
получение, обновление или отзыв сертификатов. Самое важное
и часто используемые команды будут обсуждаться в этом
документ; исчерпывающий список также появляется в конце документа.

Сценарий certbot на вашем веб-сервере может называться letsencrypt , если ваша система использует более старый пакет, или certbot-auto , если вы использовали альтернативный метод установки.В документации всякий раз, когда вы видите certbot , при необходимости замените правильное имя.

Клиент Certbot поддерживает два типа плагинов для
получение и установка сертификатов: аутентификаторы и инсталляторы.

Authenticators — это плагины, используемые с командой certonly для получения сертификата.
Аутентификатор подтверждает, что вы
контролировать домен (ы), для которых вы запрашиваете сертификат, получает сертификат для указанного
домена (ов) и помещает сертификат в каталог / etc / letsencrypt на вашем
машина.Аутентификатор не устанавливает сертификат (он не редактирует файлы конфигурации вашего сервера для обслуживания
получен сертификат). Если вы укажете несколько доменов для аутентификации, они будут
все должны быть перечислены в одном сертификате. Чтобы получить несколько отдельных сертификатов
вам нужно будет запустить Certbot несколько раз.

Установщики

— это плагины, используемые с командой install для установки сертификата.
Эти плагины могут изменять конфигурацию вашего веб-сервера на
обслуживать ваш сайт через HTTPS, используя сертификаты, полученные certbot.

Плагины

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

Плагин Auth Inst Банкноты Типы вызовов (и порт)
apache Y Y

Автоматизирует получение и установку сертификата с помощью Apache.

 http-01 (80)
nginx Y Y

Автоматизирует получение и установку сертификата с помощью Nginx.

 http-01 (80)
веб-корень Y N

Получает сертификат путем записи в корневой веб-каталог

уже запущенный веб-сервер.

 http-01 (80)
автономный Y N

Использует «автономный» веб-сервер для получения сертификата.

Требуется, чтобы был доступен порт 80. Это полезно на

Системы

без веб-сервера или при прямой интеграции с

локальный веб-сервер не поддерживается или нежелателен.

 http-01 (80)
Плагины DNS Y N

Эта категория плагинов автоматизирует получение сертификата по

изменение записей DNS, чтобы доказать, что вы контролируете

домен. Выполнение проверки домена таким образом —

единственный способ получить групповые сертификаты от Let’s

Шифрование.

 днс-01 (53)
инструкция Y N

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

выполните проверку домена самостоятельно. Дополнительно позволяет

, чтобы указать сценарии для автоматизации задачи проверки в

индивидуальный способ.

 http-01 (80) или
dns-01 (53)

Под капотом плагины используют одну из нескольких проблем протокола ACME для
докажите, что вы контролируете домен.Возможные варианты: http-01 (который использует порт 80).
и dns-01 (требуется настройка DNS-сервера на
порт 53, хотя часто это не тот же компьютер, что и ваш веб-сервер). Немного
плагины поддерживают более одного типа задачи, и в этом случае вы можете выбрать один
с --preferred-calls .

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

Apache

Плагин Apache в настоящее время поддерживает
современные ОС на базе Debian, Fedora, SUSE, Gentoo и Darwin.Это автоматизирует получение сертификатов и при установке на Apache.
веб сервер. Чтобы указать этот плагин в командной строке, просто включите
--apache .

Webroot

Если вы используете локальный веб-сервер, для которого у вас есть возможность
чтобы изменить обслуживаемый контент, и вы бы предпочли не останавливать
веб-сервер во время процесса выдачи сертификата, вы можете использовать веб-сервер
плагин для получения сертификата, включив certonly и --webroot в
командная строка.Кроме того, вам необходимо указать --webroot-path
или -w с каталогом верхнего уровня («веб-корень»), содержащим файлы
обслуживается вашим веб-сервером. Например, --webroot-path / var / www / html
или --webroot-path / usr / share / nginx / html — два общих пути к корневому веб-каталогу.

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

 certbot certonly --webroot -w / var / www / example -d www.example.com -d example.com -w / var / www / other -d other.example.net -d another.other.example.net

получит единый сертификат для всех этих имен, используя
/ var / www / example корневой каталог для первых двух и
/ var / www / other для вторых двух.

Плагин webroot работает, создавая временный файл для каждого из запрошенных вами
домены в $ {webroot-path} /. well-known / acme-challenge . Тогда Let’s Encrypt
сервер проверки делает HTTP-запросы для проверки того, что DNS для каждого
запрошенный домен разрешается на сервер, на котором запущен certbot. Пример запроса
на ваш веб-сервер будет выглядеть так:

 66.133.109.36 - - [05 / Янв / 2016: 20: 11: 24 -0500] "GET /.well-known/acme-challenge/HGr8U1IeTW4kY_Z6UIyaakzOkyQgPr_7ArlLgtZE8SX HTTP / 1.1 "200 87" - "" Mozilla / 5.0 (совместимый; сервер проверки Let's Encrypt; + https: //www.letsencrypt.org) "

Обратите внимание, что для использования подключаемого модуля webroot ваш сервер должен быть настроен для обслуживания
файлы из скрытых каталогов. Если /. well-known лечится специально
конфигурация вашего веб-сервера, вам может потребоваться изменить конфигурацию
чтобы файлы внутри /.well-known/acme-challenge обслуживались
веб-сервер.

Nginx

Плагин Nginx должен работать для большинства конфигураций.Мы рекомендуем сделать резервную копию
Конфигурации Nginx перед его использованием (хотя вы также можете вернуть изменения в
конфигурации с certbot --nginx rollback ). Вы можете использовать его, предоставив
флаг --nginx в командной строке.

Автономный

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

Чтобы получить сертификат с помощью «автономного» веб-сервера, вы можете использовать
автономный плагин, включающий certonly и - standalone
в командной строке. Этот плагин необходимо привязать к порту 80 в
чтобы выполнить проверку домена, поэтому вам может потребоваться остановить
существующий веб-сервер.

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

По умолчанию Certbot сначала пытается привязаться к порту для всех интерфейсов, используя
IPv6 с последующей привязкой к этому порту с помощью IPv4; Certbot работает до тех пор, пока на
по крайней мере, одна привязка завершится успешно.В большинстве систем Linux трафик IPv4 будет направляться на
связанный порт IPv6 и ожидается сбой во время второй привязки.

Используйте - -address , чтобы явно указать Certbot, какой интерфейс
(и протокол) для привязки.

Плагины DNS

Если вы хотите получить групповой сертификат от Let’s Encrypt или запустите
certbot на машине, отличной от вашего целевого веб-сервера, вы можете использовать один из
Плагины Certbot для DNS.

Эти плагины не входят в стандартную установку Certbot и должны быть
устанавливается отдельно.Хотя плагины DNS в настоящее время не могут использоваться с
certbot-auto , они доступны во многих менеджерах пакетов ОС, как Docker
изображения и снимки. Посетите https://certbot.eff.org, чтобы узнать, как лучше всего использовать
плагины DNS в вашей системе.

После установки вы можете найти документацию по использованию каждого плагина по адресу:

Руководство

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

Плагин руководства может использовать вызов http или dns . Вы можете использовать опцию --preferred-calls
выбрать вызов по своему вкусу.

Задача http попросит вас поместить файл с определенным именем и
конкретное содержание в /.каталог well-known / acme-challenge / напрямую
в каталоге верхнего уровня («веб-корень»), содержащем файлы, обслуживаемые вашим
веб сервер. По сути, это то же самое, что и плагин webroot, но не автоматизировано.

При использовании задачи dns certbot попросит вас разместить TXT DNS
запись с определенным содержанием под доменным именем, состоящим из имени хоста
для которого вы хотите выдать сертификат с добавлением _acme-challenge .

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

 _acme-challenge.example.com. 300 IN TXT "gfj9Xq ... Rg85nM"

Дополнительно вы можете указать сценарии для подготовки к проверке и
выполнить процедуру аутентификации и / или очистить после нее, используя
флаги --manual-auth-hook и --manual-cleanup-hook . Это
более подробно описано в разделе хуков.

Объединение плагинов

Иногда может потребоваться указать комбинацию отдельного аутентификатора и
плагины установщика.Для этого укажите плагин аутентификатора с помощью
--authenticator или -a и плагин установщика с --installer или
-i .

Например, вы можете создать сертификат с помощью плагина webroot
для аутентификации и плагин apache для установки.

 certbot run -a webroot -i apache -w / var / www / html -d example.com

Или вы можете создать сертификат, используя ручной плагин для аутентификации
и плагин nginx для установки.(Обратите внимание, что этот сертификат не может
продлеваться автоматически.)

 certbot run -a manual -i nginx -d example.com

Сторонние плагины

Существует также ряд сторонних плагинов для клиента, предоставляемых
другие разработчики. Многие из них находятся в стадии бета-тестирования, но некоторые уже находятся в
широкое использование:

Плагин Auth Inst Банкноты
haproxy Y Y Интеграция с балансировщиком нагрузки HAProxy
s3 передняя Y Y Интеграция с Amazon CloudFront распространение корзин S3
Ганди Y N Получить сертификаты через Gandi LiveDNS API
лак Y N Получить сертификаты через сервер Varnish
внешняя авторизация Y Y Плагин для удобного написания скриптов
притунл N Y Установить сертификаты в притунл распределенных серверах OpenVPN
proxmox N Y Установить сертификаты на серверах виртуализации Proxmox
dns-автономный Y N Получить сертификаты через встроенный DNS-сервер
dns-ispconfig Y N DNS-аутентификация с использованием ISPConfig в качестве DNS-сервера
DNS-облако DNS Y N DNS-аутентификация с использованием CloudDNS API
dns-вход wx Y Y DNS-аутентификация для INWX через XML API

Если вам интересно, вы также можете написать свой собственный плагин.

Чтобы просмотреть список сертификатов, о которых знает Certbot, запустите
сертификатов подкоманда:

сертификаты certbot

Возвращает информацию в следующем формате:

 Обнаружены следующие сертификаты:
  Имя сертификата: example.com
    Домены: example.com, www.example.com
    Срок действия: 2017-02-19 19: 53: 00 + 00: 00 (ДЕЙСТВИТЕЛЬНО: 30 дней)
    Путь к сертификату: /etc/letsencrypt/live/example.com/fullchain.pem
    Путь к закрытому ключу: / etc / letsencrypt / live / example.com / privkey.pem

Имя сертификата показывает имя сертификата. Передайте это имя
используя флаг --cert-name , чтобы указать конкретный сертификат для запуска ,
certonly , сертификаты , обновить и удалить команд. Пример:

 certbot certonly --cert-name example.com

Повторное создание и обновление существующих сертификатов

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

Если сертификат запрашивается с запуском или Certonly с указанием
имя сертификата, которое уже существует, Certbot обновляет
существующий сертификат. В противном случае новый сертификат
создается и получает указанное имя.

- принудительное обновление , - дублирование и - развернуть вариантов
контролировать поведение Certbot при воссоздании
сертификат с тем же именем, что и существующий сертификат.
Если вы не укажете запрошенное поведение, Certbot может спросить вас, что вы хотели.

--force-возобновление сообщает Certbot запросить новый сертификат
с теми же доменами, что и существующий сертификат. Каждый домен
должно быть явно указано через -d . В случае успеха этот сертификат
сохраняется вместе с предыдущей и символическими ссылками (« live »
ссылка) будет обновлено, чтобы указать на новый сертификат. Это
действующий способ продления конкретного физического лица
сертификат.

--duplicate сообщает Certbot о необходимости создания отдельного несвязанного сертификата
с теми же доменами, что и существующий сертификат.Этот сертификат
сохранены полностью отдельно от предыдущей. Большинство пользователей не будут
Эту команду необходимо вводить в нормальных условиях.

--expand указывает Certbot обновить существующий сертификат новым
сертификат, содержащий все старые домены и один или несколько дополнительных
новые домены. С параметром --expand используйте параметр -d , чтобы указать
все существующие домены и один или несколько новых доменов.

Пример:

 certbot --expand -d существующий.com, example.com, newdomain.com

При желании вы можете указать домены индивидуально следующим образом:

 certbot --expand -d existing.com -d example.com -d newdomain.com

Рассмотрите возможность использования --cert-name вместо --expand , так как это дает больше контроля
по которому был изменен сертификат, и он позволяет удалять домены, а также добавлять их.

--allow-subset-of-names сообщает Certbot продолжить создание сертификата, если
можно получить только некоторые из указанных доменных авторизаций.Это может
будет полезно, если некоторые домены, указанные в сертификате, больше не указывают на этот
система.

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

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

Флаг --cert-name также может использоваться для изменения доменов, содержащихся в сертификате,
путем указания новых доменов с помощью флага -d или --domains .Если сертификат example.com
ранее содержалось example.com и www.example.com , его можно изменить только на
содержать example.com , указав только example.com с флагом -d или --domains . Пример:

 certbot certonly --cert-name example.com -d example.com

Тот же формат можно использовать для расширения набора доменов, содержащихся в сертификате, или для
полностью заменить этот набор:

 certbot certonly --cert-name example.com -d example.org, www.example.org

Отзыв сертификатов

Если ключ вашей учетной записи был взломан или вам необходимо отозвать сертификат по иным причинам,
для этого используйте команду revoke . Обратите внимание, что команда revoke принимает путь сертификата
(оканчивается на cert.pem ), а не на имя сертификата или домен. Пример:

 certbot revoke --cert-path /etc/letsencrypt/live/CERTNAME/cert.pem

Вы также можете указать причину отзыва сертификата с помощью флага cause .Причины включают неуказанный , который используется по умолчанию, а также keycompromise ,
изменена принадлежность , заменена и прекращена работа :

 certbot revoke --cert-path /etc/letsencrypt/live/CERTNAME/cert.pem --reason keycompromise

Дополнительно, если сертификат
это тестовый сертификат, полученный с помощью флага --staging или --test-cert , этот флаг должен быть передан в
отменить подкоманду .После отзыва сертификата (или для других задач управления сертификатами) все сертификаты
соответствующие файлы могут быть удалены из системы с помощью подкоманды delete :

 certbot delete --cert-name example.com

Примечание

Если вы не используете delete для полного удаления сертификата, он будет автоматически продлен при следующем обновлении.

Примечание

Отзыв сертификата не повлияет на ограничение скорости, установленное сервером Let’s Encrypt.

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

Примечание

Let’s Encrypt CA выдает краткосрочные сертификаты (90
дней). Убедитесь, что вы обновляете сертификаты хотя бы раз в 3
месяцы.

См. Также

Многие клиенты certbot, полученные через
раздача идет с автоматическим продлением из коробки,
такие как версии Debian и Ubuntu, установленные через apt ,
CentOS / RHEL 7 через EPEL и т. Д. См. Автоматическое продление
Больше подробностей.

Начиная с версии 0.10.0, Certbot поддерживает действие , продлить для проверки
все установленные сертификаты для приближающегося истечения срока действия и попытки продлить
их. Самая простая форма — это просто

.

certbot обновить

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

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

 certbot refresh --pre-hook "service nginx stop" --post-hook "service nginx start"

Если ловушка завершается с ненулевым кодом выхода, будет напечатана ошибка
на stderr , но все равно будет предпринята попытка продления. Неудачный крючок
не вызывает непосредственного выхода Certbot с ненулевым кодом выхода, но
поскольку Certbot завершает работу с ненулевым кодом выхода при неудачном продлении,
неудачный перехватчик, вызывающий сбои при обновлении, косвенно приведет к
ненулевой код выхода. Хуки будут запускаться только в том случае, если требуется сертификат для
обновление, поэтому вы можете часто запускать указанную выше команду без
излишняя остановка вашего веб-сервера.

Когда Certbot обнаруживает, что сертификат подлежит обновлению, --pre-hook
и --post-hook обработчиков запускаются до и после каждой попытки его обновления.
Если вы хотите, чтобы ваш хук запускался только после успешного обновления, используйте
--deploy-hook в такой команде.

certbot обновить --deploy-hook / path / to / deploy-hook-script

Вы также можете указать перехватчики, поместив файлы в подкаталоги Certbot
каталог конфигурации. Предполагая, что ваш каталог конфигурации
/ etc / letsencrypt , любые исполняемые файлы, найденные в
/ и т.д. / letsencrypt / возобновление-крючки / до ,
/ etc / letsencrypt / Renewal-hooks / deploy и
/ etc / letsencrypt / Renewal-hooks / post будет запускаться как до, развертывания и публикации
крючки соответственно, когда любой сертификат обновляется с возобновить
подкоманда.Эти хуки запускаются в алфавитном порядке и не запускаются для других
подкоманды. (Порядок запуска хуков определяется байтовым значением
символов в их именах файлов и не зависит от вашей локали.)

Хуки, указанные в командной строке, файле конфигурации или файлах конфигурации обновления, являются
запускается как обычно после запуска всех хуков в этих каталогах. Одно небольшое исключение
к этому, если хук, указанный в другом месте, является просто путем к исполняемому файлу
файл в каталоге хуков того же типа (например,г. ваш предварительный зацеп — это путь к
исполняемый файл в / etc / letsencrypt / Renewal-hooks / pre ), файл не запускается
второй раз. Вы можете запретить Certbot автоматически запускать найденные исполняемые файлы
в этих каталогах, включив --no-directory-hooks в командную строку.

Более подробную информацию о хуках можно найти, запустив
certbot - помочь обновить .

Если вы уверены, что эта команда выполняется успешно без участия человека
вмешательства, вы можете добавить команду crontab (поскольку сертификаты
обновляются только тогда, когда срок их действия истекает, команда
можно бегать регулярно, например каждую неделю или каждый день).В этом случае,
вы, вероятно, захотите использовать флаг -q или --quiet quiet, чтобы
отключить весь вывод, кроме ошибок.

Если вы вручную обновляете все свои сертификаты,
- флаг принудительного обновления может быть полезен; это приводит к истечению срока действия
сертификат (ы), которые следует игнорировать при рассмотрении вопроса о продлении, и пытается
обновлять каждый установленный сертификат независимо от его возраста. (Эта
форма не подходит для ежедневного запуска, потому что каждый сертификат будет
обновляется каждый день, что быстро попадет в центр сертификации
ограничение скорости.)

Обратите внимание, что параметры, предоставленные для обновления certbot , будут применяться к
каждый сертификат , продление которого предпринимается; например,
certbot обновить --rsa-key-size 4096 будет пытаться заменить каждый
почти истекающий сертификат с эквивалентным сертификатом, использующим 4096-битный
Открытый ключ RSA. Если сертификат успешно продлен с помощью
указанные параметры, эти параметры будут сохранены и использованы в будущем
продления этого сертификата.

Альтернативная форма, обеспечивающая более детальный контроль над
процесс обновления (при обновлении указанных сертификатов по одному),
это certbot certonly с полным набором предметных доменов
конкретный сертификат, указанный с помощью флагов -d .Вы также можете захотеть
включите флаг -n или --noninteractive для предотвращения блокировки на
пользовательский ввод (что полезно при запуске команды из cron).

certbot certonly -n -d example.com -d www.example.com

Все домены, на которые распространяется сертификат, должны быть указаны в
в этом случае, чтобы обновить и заменить старый сертификат, а
чем приобретение нового; не забудьте про www. доменов! Указание
подмножество доменов создает новый отдельный сертификат, содержащий
только эти домены, а не заменять исходный сертификат.При запуске с набором доменов, соответствующих существующему сертификату,
команда certonly пытается обновить этот конкретный сертификат.

Обратите внимание, что центр сертификации будет отправлять уведомления по электронной почте на адрес
вы предоставляете, если не обновляете сертификаты, срок действия которых скоро истечет.

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

Примечание

certbot возобновить статус выхода будет только 1, если попытка обновления не удалась.Это означает, что certbot обновить статус выхода будет 0, если обновлять сертификат не нужно.
Если вы пишете собственный сценарий и ожидаете запустить команду только после фактического обновления сертификата
вам нужно будет использовать --deploy-hook , так как при успешном обновлении статус выхода будет равен 0
и когда в обновлении нет необходимости.

Изменение файла конфигурации продления

При выдаче сертификата Certbot по умолчанию создает файл конфигурации обновления, который
отслеживает параметры, выбранные при запуске Certbot.Это позволяет Certbot
использовать те же возможности снова, когда придет время продления. Это обновление
файлы конфигурации расположены по адресу / etc / letsencrypt / Renewal / CERTNAME .

Для расширенных задач управления сертификатами можно вручную изменить
файл конфигурации обновления, но это не рекомендуется, поскольку он может легко нарушить работу Certbot
возможность продления сертификатов. Если вы решите изменить файл конфигурации продления
мы советуем вам проверить его действительность с помощью команды certbot Renew --dry-run .

Предупреждение

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

Для большинства задач безопаснее всего ограничиться указанием символических ссылок на файлы или использовать
--deploy-hook для копирования / создания новых файлов на основе этих файлов, если этого требует ваша рабочая ситуация
(например, объединение сертификатов и ключей по-разному, или наличие копий вещей с разными
определенные разрешения, которые требуются другими программами).

Если содержимое / etc / letsencrypt / archive / CERTNAME перемещается в новую папку, сначала укажите
имя новой папки в файле конфигурации обновления, затем запустите certbot update_symlinks , чтобы
укажите символические ссылки в / etc / letsencrypt / live / CERTNAME в новую папку.

Если вы хотите, чтобы файлы действующего сертификата, расположение символической ссылки которых Certbot обновлялось при каждом запуске, были
находятся в другом месте, сначала переместите их в это место, затем укажите полный путь к
каждый из четырех файлов в файле конфигурации обновления.Поскольку символические ссылки являются относительными ссылками,
после этого вы должны вызвать certbot update_symlinks .

Например, предположим, что файл конфигурации продления сертификата ранее содержал следующее
директивы:

 каталог_архива = /etc/letsencrypt/archive/example.com
cert = /etc/letsencrypt/live/example.com/cert.pem
Privkey = /etc/letsencrypt/live/example.com/privkey.pem
цепочка = /etc/letsencrypt/live/example.com/chain.pem
fullchain = / etc / letsencrypt / live / example.com / fullchain.pem

Следующие команды могут использоваться, чтобы указать, где находятся эти файлы:

 mv /etc/letsencrypt/archive/example.com / home / user / me / certbot / example_archive
sed -i, / etc / letsencrypt / archive / example.com, / home / user / me / certbot / example_archive, '/etc/letsencrypt/renewal/example.com.conf
mv /etc/letsencrypt/live/example.com/*.pem / home / user / me / certbot /
sed -i, / etc / letsencrypt / live / example.com, / home / user / me / certbot, g '/ etc / letsencrypt / Renewal / example.com.conf
certbot update_symlinks

Автоматическое продление

Многие дистрибутивы Linux обеспечивают автоматическое продление при использовании
пакеты, установленные через их системный менеджер пакетов. В
Следующая таблица представляет собой неполный список распределений, которые это делают,
а также их методы для этого.

Если вы не уверены, есть ли это в вашей системе
автоматизировано, обратитесь к документации вашего дистрибутива или проверьте свой
системный crontab (обычно в / etc / crontab / и / etc / cron.* / * и
таймеры systemd ( таймеров списка systemctl ).

Распределения с автоматическим продлением
Название распространения Версия распространения Метод автоматизации
CentOS EPEL 7 systemd
Debian растяжка cron, systemd
Debian тестирование / sid cron, systemd
Fedora 26 systemd
Fedora 27 systemd
RHEL EPEL 7 systemd
Ubuntu 17.10 cron, systemd
Ubuntu certbot PPA cron, systemd

Все сгенерированные ключи и выданные сертификаты можно найти в
/ etc / letsencrypt / live / $ domain . В случае создания сертификата SAN
с несколькими альтернативными именами $ домен — это первый домен, переданный в
через параметр -d. Вместо копирования укажите
конфигурацию вашего (веб) сервера непосредственно в эти файлы (или создайте
символические ссылки).Во время обновления обновляется / etc / letsencrypt / live
с последними необходимыми файлами.

По историческим причинам содержащие каталоги создаются с
разрешения 0700 означают, что сертификаты доступны только
к серверам, которые работают от имени пользователя root. Если вы никогда не переходите на более раннюю версию
на более старую версию Certbot , тогда вы можете безопасно исправить это, используя
chmod 0755 / etc / letsencrypt / {live, archive} .

Для серверов, которые отбрасывают привилегии root перед попыткой чтения
файл закрытого ключа, вам также необходимо использовать chgrp и chmod
0640 , чтобы сервер мог читать
/ etc / letsencrypt / live / $ domain / privkey.pem .

Примечание

/ etc / letsencrypt / archive и / etc / letsencrypt / keys
содержат все предыдущие ключи и сертификаты, а
/ etc / letsencrypt / live символические ссылки на последние версии.

Доступны следующие файлы:

privkey.pem

Закрытый ключ для сертификата.

Предупреждение

Этот должен всегда храниться в секрете ! Никогда не делись
это с кем угодно, включая разработчиков Certbot.Ты не можешь
однако положите его в сейф — вашему серверу по-прежнему нужен доступ
этот файл для работы SSL / TLS.

Примечание

Начиная с версии Certbot 0.29.0, закрытые ключи для нового сертификата
по умолчанию 0600 . Любые изменения режима группы или владельца группы (gid)
этого файла будут сохранены при продлении.

Это то, что нужно Apache для SSLCertificateKeyFile,
и Nginx для ssl_certificate_key.

fullchain.pem

Все сертификаты, включая сертификат сервера (также известный как листовой сертификат или
сертификат конечного объекта).Сертификат сервера является первым в этом файле,
за которыми следуют любые промежуточные звенья.

Это то, что нужно Apache> = 2.4.8 для SSLCertificateFile,
и что нужно Nginx для ssl_certificate.

cert.pem и chain.pem (реже)

cert.pem содержит сам сертификат сервера и
chain.pem содержит дополнительный промежуточный сертификат или
сертификаты, которые потребуются веб-браузерам для проверки
сертификат сервера.Если вы предоставите один из этих файлов в свой Интернет
сервер, вы должны предоставить оба из них, иначе некоторые браузеры будут отображать
Иногда возникает ошибка «Это соединение не является доверенным» для вашего сайта.

Apache <2.4.8 они нужны для SSLCertificateFile. и SSLCertificateChainFile, соответственно.

Если вы используете сшивание OCSP с Nginx> = 1.3.7, chain.pem должен быть
предоставляется как ssl_trusted_certificate
для проверки ответов OCSP.

Примечание

Все файлы закодированы в формате PEM.Если вам нужен другой формат, например DER или PFX, тогда вы
можно преобразовать с использованием openssl . Вы можете автоматизировать это с помощью
--deploy-hook , если вы используете автоматическое продление.

Certbot позволяет указывать хуки до и после проверки при запуске
в ручном режиме. Флаги для указания этих сценариев: --manual-auth-hook
и - крюк ручной очистки соответственно и может использоваться следующим образом:

 certbot certonly --manual --manual-auth-hook / путь / к / http / аутентификатору.sh --manual-cleanup-hook /path/to/http/cleanup.sh -d secure.example.com

Это запустит сценарий Authenticator.sh , попытается выполнить проверку, а затем запустит
сценарий cleanup.sh . Дополнительно certbot пройдет соответствующую среду
переменные к этим скриптам:

  • CERTBOT_DOMAIN : аутентифицируемый домен
  • CERTBOT_VALIDATION : строка проверки
  • CERTBOT_TOKEN : имя ресурса, часть запроса HTTP-01 (только HTTP-01)
  • CERTBOT_REMAINING_CHALLENGES : количество вызовов, оставшихся после текущего вызова
  • CERTBOT_ALL_DOMAINS : разделенный запятыми список всех доменов, запрашиваемых для текущего сертификата

Дополнительно для очистки:

  • CERTBOT_AUTH_OUTPUT : все, что сценарий аутентификации записал в стандартный вывод

Пример использования HTTP-01:

 certbot certonly --manual --preferred-issues = http --manual-auth-hook / path / to / http / authentication.sh --manual-cleanup-hook /path/to/http/cleanup.sh -d secure.example.com

/path/to/http/authenticator.sh

 #! / Bin / bash
echo $ CERTBOT_VALIDATION> /var/www/htdocs/.well-known/acme-challenge/$CERTBOT_TOKEN

/path/to/http/cleanup.sh

 #! / Bin / bash
rm -f /var/www/htdocs/.well-known/acme-challenge/$CERTBOT_TOKEN

Пример использования DNS-01 (Cloudflare API v4) (только для примера, не используйте как есть)

 certbot certonly --manual --preferred-issues = dns --manual-auth-hook / path / to / dns / authentication.sh --manual-cleanup-hook /path/to/dns/cleanup.sh -d secure.example.com

/path/to/dns/authenticator.sh

 #! / Bin / bash

# Получите свой ключ API с https://www.cloudflare.com/a/account/my-account
API_KEY = "ваш-API-ключ"
EMAIL = "[email protected]"

# Удалите только верхний домен, чтобы получить идентификатор зоны
DOMAIN = $ (expr match "$ CERTBOT_DOMAIN" '. * \. \ (. * \ .. * \)')

# Получить идентификатор зоны Cloudflare
ZONE_EXTRA_PARAMS = "status = active & page = 1 & per_page = 20 & order = status & direction = desc & match = all"
ZONE_ID = $ (curl -s -X GET "https: // api.cloudflare.com/client/v4/zones?name=$DOMAIN&$ZONE_EXTRA_PARAMS "\
     -H "X-Auth-Email: $ EMAIL" \
     -H "X-Auth-Key: $ API_KEY" \
     -H "Content-Type: application / json" | python -c "import sys, json; print (json.load (sys.stdin) ['result'] [0] ['id'])»)

# Создать запись TXT
CREATE_DOMAIN = "_ acme-challenge. $ CERTBOT_DOMAIN"
RECORD_ID = $ (curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
     -H "X-Auth-Email: $ EMAIL" \
     -H "X-Auth-Key: $ API_KEY" \
     -H "Content-Type: application / json" \
     --data '{"type": "TXT", "name": "'" $ CREATE_DOMAIN "'", "content": "'" $ CERTBOT_VALIDATION "'", "ttl": 120}' \
             | python -c "import sys, json; print (json.load (sys.stdin) ['результат'] ['идентификатор']) ")
# Сохранить информацию для очистки
если [ ! -d / tmp / CERTBOT_ $ CERTBOT_DOMAIN]; затем
        mkdir -m 0700 / tmp / CERTBOT_ $ CERTBOT_DOMAIN
фи
echo $ ZONE_ID> / tmp / CERTBOT_ $ CERTBOT_DOMAIN / ZONE_ID
echo $ RECORD_ID> / tmp / CERTBOT_ $ CERTBOT_DOMAIN / RECORD_ID

# Спать, чтобы убедиться, что изменение успело распространиться на DNS
спать 25

/path/to/dns/cleanup.sh

 #! / Bin / bash

# Получите свой ключ API с https://www.cloudflare.com/a/account/my-account
API_KEY = "ваш-API-ключ"
EMAIL = "ваш[email protected] "

если [-f / tmp / CERTBOT_ $ CERTBOT_DOMAIN / ZONE_ID]; тогда
        ZONE_ID = $ (cat / tmp / CERTBOT_ $ CERTBOT_DOMAIN / ZONE_ID)
        rm -f / tmp / CERTBOT_ $ CERTBOT_DOMAIN / ZONE_ID
фи

если [-f / tmp / CERTBOT_ $ CERTBOT_DOMAIN / RECORD_ID]; тогда
        RECORD_ID = $ (cat / tmp / CERTBOT_ $ CERTBOT_DOMAIN / RECORD_ID)
        rm -f / tmp / CERTBOT_ $ CERTBOT_DOMAIN / RECORD_ID
фи

# Удаляем TXT-запись вызова из зоны
если [-n "$ {ZONE_ID}"]; тогда
    если [-n "$ {RECORD_ID}"]; тогда
        curl -s -X DELETE "https: // api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID "\
                -H "X-Auth-Email: $ EMAIL" \
                -H "X-Auth-Key: $ API_KEY" \
                -H "Content-Type: application / json"
    фи
фи

.

No related posts.

Share :

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *