Как установить certbot ubuntu
Установка Certbot в Ubuntu
На тесте установлю ACME клиент Certbot в Ubuntu 18.04, который поможет получить бесплатные SSL сертификаты Let’s Encrypt на 90 дней и автоматически обновлять их.
Для других версий Ubuntu клиент Certbot устанавливается аналогично.
Первым делом добавим репозиторий Certbot и выполним установку:
В разных версиях Linux пакет может называться по разному, например:
Если вместо apache2 используется nginx, то вместо последней команды выполним:
Теперь запустим Certbot чтобы получить SSL сертификат:
Чтобы вручную внести изменения в конфигурацию Apache2 и Certbot не изменял её, можно выполнить команду:
После запуска команды, необходимо выбрать сайт для которого будет запрашиваться SSL сертификат.
После получения сертификата отобразилась информация:
IMPORTANT NOTES:
— Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/privkey.pem
Your cert will expire on 2018-08-01. 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.
Создался отдельный файл конфигурации сайта для HTTPS, а в том что был добавились строки выполняющие переадресацию с HTTP на HTTPS, общем аналогичные изменения как я описывал в этой статье — Установка и настройка Let’s Encrypt SSL.
Для автоматического обновления необходимо выполнить команду:
Команду также можно добавить в Cron для автоматического обновления, смотрите мою статью — Использование и настройка CRON
Пример добавления в Cron (каждый понедельник в 3:15):
Если сертификаты указаны также в Postfix и Dovecot, то эти службы нужно перезапускать чтобы загрузился новый сертификат, это можно сделать добавив к команде:
Для тестового обновления можно выполнить команду (конфигурация и сертификаты не будут затронуты):
Если срок сертификата еще не истекает и запустить обновление, то ничего не произойдет.
Для обновления сертификатов apache2 также должен работать на 80 порту.
Чтобы обновить версию самого Certbot, выполним команды:
Если certbot был установлен например с apache2, а потом apache2 удалили и установили nginx, то в файлах /etc/letsencrypt/renewal/* нужно изменить «authenticator» и «installer».
Для удаления сертификата и всех связанных с ним данных используется команда (после ввода необходимо выбрать домен):
Certbot Instructions
Apache on Ubuntu 20
A command line is a way of interacting with a computer by typing text-based commands to it and receiving text-based replies. Certbot is run from a command-line interface, usually on a Unix-like server. In order to use Certbot for most purposes, you’ll need to be able to install and run it on the command line of your web server, which is usually accessed over SSH.
A command line is a way of interacting with a computer by typing text-based commands to it and recei.
A command line is a way of interacting with a computer by typing text-based commands to it and receiving text-based replies. Certbot is run from a command-line interface, usually on a Unix-like server. In order to use Certbot for most purposes, you’ll need to be able to install and run it on the command line of your web server, which is usually accessed over SSH.
HTTP (Hypertext Transfer Protocol) is the traditional, but insecure, method for web browsers to request the content of web pages and other online resources from web servers. It is an Internet standard and normally used with TCP port 80. Almost all websites in the world support HTTP, but websites that have been configured with Certbot or some other method of setting up HTTPS may automatically redirect users from the HTTP version of the site to the HTTPS version.
HTTP (Hypertext Transfer Protocol) is the traditional, but insecure, method for web browsers to requ.
HTTP (Hypertext Transfer Protocol) is the traditional, but insecure, method for web browsers to request the content of web pages and other online resources from web servers. It is an Internet standard and normally used with TCP port 80. Almost all websites in the world support HTTP, but websites that have been configured with Certbot or some other method of setting up HTTPS may automatically redirect users from the HTTP version of the site to the HTTPS version.
Certbot is usually meant to be used to switch an existing HTTP site to work in HTTPS (and, afterward, to continue renewing the site’s HTTPS certificates whenever necessary). Some Certbot documentation assumes or recommends that you have a working web site that can already be accessed using HTTP on port 80. That means, for example, that if you use a web browser to go to your domain using http://, your web server answers and some kind of content comes up (even if it’s just a default welcome page rather than the final version of your site). Some methods of using Certbot have this as a prerequisite, so you’ll have a smoother experience if you already have a site set up with HTTP. (If your site can’t be accessed this way as a matter of policy, you’ll probably need to use DNS validation in order to get a certificate with Certbot.)
Certbot is usually meant to be used to switch an existing HTTP site to work in HTTPS (and, afterward.
Certbot is usually meant to be used to switch an existing HTTP site to work in HTTPS (and, afterward, to continue renewing the site’s HTTPS certificates whenever necessary). Some Certbot documentation assumes or recommends that you have a working web site that can already be accessed using HTTP on port 80. That means, for example, that if you use a web browser to go to your domain using http://, your web server answers and some kind of content comes up (even if it’s just a default welcome page rather than the final version of your site). Some methods of using Certbot have this as a prerequisite, so you’ll have a smoother experience if you already have a site set up with HTTP. (If your site can’t be accessed this way as a matter of policy, you’ll probably need to use DNS validation in order to get a certificate with Certbot.)
A server is a computer on the Internet that provides a service, like a web site or an email service. Most web site owners pay a hosting provider for the use of a server located in a data center and administered over the Internet. This might be a physical dedicated server, a virtual private server (VPS), or a shared server. Other servers provide other parts of the Internet infrastructure, such as DNS servers.
A server is a computer on the Internet that provides a service, like a web site or an email service.
A server is a computer on the Internet that provides a service, like a web site or an email service. Most web site owners pay a hosting provider for the use of a server located in a data center and administered over the Internet. This might be a physical dedicated server, a virtual private server (VPS), or a shared server. Other servers provide other parts of the Internet infrastructure, such as DNS servers.
SSH (which stands for “secure shell”) is a technology for connecting to a remote server and accessing a command line on that server, often in order to administer it. The administrator of a server can grant SSH access to others, and can also use SSH access directly in order to administer the server remotely. SSH is usually used to access servers running Unix-like operating systems, but your own computer doesn’t have to be running Unix in order to use SSH. You normally use SSH from your computer’s command line in a terminal by typing a command such as ssh username@example.com, especially if your own computer runs Linux or macOS. After logging in, you’ll have access to the server’s command line. If you use Windows on your computer, you might also use a dedicated SSH application such as PuTTY. Most Certbot users run Certbot from a command prompt on a remote server over SSH.
SSH (which stands for “secure shell”) is a technology for connecting to a remote server and accessin.
SSH (which stands for “secure shell”) is a technology for connecting to a remote server and accessing a command line on that server, often in order to administer it. The administrator of a server can grant SSH access to others, and can also use SSH access directly in order to administer the server remotely. SSH is usually used to access servers running Unix-like operating systems, but your own computer doesn’t have to be running Unix in order to use SSH. You normally use SSH from your computer’s command line in a terminal by typing a command such as ssh username@example.com, especially if your own computer runs Linux or macOS. After logging in, you’ll have access to the server’s command line. If you use Windows on your computer, you might also use a dedicated SSH application such as PuTTY. Most Certbot users run Certbot from a command prompt on a remote server over SSH.
Sudo is the most common command on Unix-like operating systems to run a specific command as root (the system administrator). If you’re logged in to your server as a user other than root, you’ll likely need to put sudo before your Certbot commands so that they run as root (for example, sudo certbot instead of just certbot), especially if you’re using Certbot’s integration with a web server like Apache or Nginx. (The certbot-auto script automatically runs sudo if it’s necessary and you didn’t specify it.)
Sudo is the most common command on Unix-like operating systems to run a specific command as root (th.
Sudo is the most common command on Unix-like operating systems to run a specific command as root (the system administrator). If you’re logged in to your server as a user other than root, you’ll likely need to put sudo before your Certbot commands so that they run as root (for example, sudo certbot instead of just certbot), especially if you’re using Certbot’s integration with a web server like Apache or Nginx. (The certbot-auto script automatically runs sudo if it’s necessary and you didn’t specify it.)
DNS credentials are a password or other kind of secret (such as an API key) that your DNS provider lets you use to change the contents of your DNS records. They are usually issued by your domain registrar (or by another DNS provider, if your DNS provider isn’t the same as your registrar). DNS credentials are a sensitive kind of secret because they can be used to take over your site completely. You should never share these credentials publicly or with an unauthorized person. It can be OK to provide a copy of them to Certbot to let it perform DNS validation automatically, since it runs locally on your machine.
DNS credentials are a password or other kind of secret (such as an API key) that your DNS provider l.
DNS credentials are a password or other kind of secret (such as an API key) that your DNS provider lets you use to change the contents of your DNS records. They are usually issued by your domain registrar (or by another DNS provider, if your DNS provider isn’t the same as your registrar). DNS credentials are a sensitive kind of secret because they can be used to take over your site completely. You should never share these credentials publicly or with an unauthorized person. It can be OK to provide a copy of them to Certbot to let it perform DNS validation automatically, since it runs locally on your machine.
Don’t have these requirements?
Snap Support
The Certbot snap supports the x86_64, ARMv7, and ARMv8 architectures. While we strongly recommend that most users install Certbot through the snap, you can find alternate installation instructions here.
SSH into the server running your HTTP website as a user with sudo privileges.
You’ll need to install snapd and make sure you follow any instructions to enable classic snap support.
Run this command on the command line on the machine to install Certbot.
Execute the following instruction on the command line on the machine to ensure that the certbot command can be run.
Either get and install your certificates.
Run this command to get a certificate and have Certbot edit your apache configuration automatically to serve it, turning on HTTPS access in a single step.
Or, just get a certificate
If you’re feeling more conservative and would like to make the changes to your apache configuration by hand, run this command.
The Certbot packages on your system come with a cron job or systemd timer that will renew your certificates automatically before they expire. You will not need to run Certbot again, unless you change your configuration. You can test automatic renewal for your certificates by running this command:
The command to renew certbot is installed in one of the following locations:
To confirm that your site is set up properly, visit https://yourwebsite.com/ in your browser and look for the lock icon in the URL bar.
Snap Support
The Certbot snap supports the x86_64, ARMv7, and ARMv8 architectures. While we strongly recommend that most users install Certbot through the snap, you can find alternate installation instructions here.
See if your DNS provider is supported by Certbot by checking this list in our documentation.
Not supported?
If your DNS provider is not supported, pause here: run Certbot with the manual plugin by using these steps from our documentation.
Supported?
If your DNS provider is supported, continue with the remaining instructions below.
SSH into the server running your HTTP website as a user with sudo privileges.
You’ll need to install snapd and make sure you follow any instructions to enable classic snap support.
Run this command on the command line on the machine to install Certbot.
Execute the following instruction on the command line on the machine to ensure that the certbot command can be run.
Run this command on the command line on the machine to acknowledge that the installed plugin will have the same classic containment as the Certbot snap.
If you encounter issues with running Certbot, you may need to follow this step, then the «Install correct DNS plugin» step, again.
Run the following command, replacing
with the name of your DNS provider.
For example, if your DNS provider is Cloudflare, you’d run the following command:
You’ll need to set up DNS credentials.
Follow the steps in the «Credentials» section for your DNS provider to access or create the appropriate credential configuration file. Find credentials instructions for your DNS provider by clicking the DNS plugin’s name on the Documentation list.
Either get and install your certificates.
Or, just get a certificate
Run one of the commands in the «Examples» section of the instructions for your DNS provider.
The Certbot packages on your system come with a cron job or systemd timer that will renew your certificates automatically before they expire. You will not need to run Certbot again, unless you change your configuration. You can test automatic renewal for your certificates by running this command:
The command to renew certbot is installed in one of the following locations:
Защита Nginx с помощью Let’s Encrypt в Ubuntu 20.04
Published on June 11, 2020
Введение
Let’s Encrypt — это центр сертификации (ЦС), позволяющий легко получать и устанавливать бесплатные сертификаты TLS/SSL, что позволяет использовать на веб-серверах шифрованный трафик HTTPS. Это упрощает процесс посредством предоставления программного клиента Certbot, который пытается автоматизировать большинство необходимых шагов (или все шаги). В настоящее время весь процесс получения и установки сертификата полностью автоматизирован — как в Apache, так и Nginx.
В этом обучающем модуле мы используем Certbot для получения бесплатного сертификата SSL для Nginx в Ubuntu 20.04 и настройки сертификата для автоматического продления.
Вместо файла по умолчанию мы будем использовать отдельный файл конфигурации сервера Nginx. Мы рекомендуем создавать новые файлы серверных блоков Nginx для каждого домена, потому что это помогает избежать распространенных ошибок и сохранять файлы по умолчанию в качестве резервной конфигурации на случай отката.
Предварительные требования
Для данного обучающего руководства вам потребуется следующее:
Один сервер Ubuntu 20.04, настроенный в соответствии с обучающим модулем Начальная настройка сервера Ubuntu 20.04, включая пользователя без прав root с привилегиями sudo и брандмауэр.
На вашем сервере должны быть настроены обе нижеследующие записи DNS. Если вы используете DigitalOcean, ознакомьтесь с нашей документацией по DNS для получения подробной информации по их добавлению.
Шаг 1 — Установка Certbot
Первый шаг для получения сертификата SSL от Let’s Encrypt — установить на сервере программное обеспечение Certbot.
Установите Certbot и его плагин Nginx с помощью apt :
Теперь Certbot готов к использованию, но для автоматической настройки конфигурации SSL для Nginx нам нужно частично проверить конфигурацию Nginx.
Шаг 2 — Настройка конфигурации Nginx
Для проверки откройте файл конфигурации вашего домена в nano или другом предпочитаемом текстовом редакторе:
Если все нормально, закройте редактор и переходите к следующему шагу.
Если нет, проведите обновление. Затем сохраните файл, закройте редактор и проверьте синтаксис внесенных правок конфигурации:
Если вы получите сообщение об ошибке, откройте файл серверного блока заново и проверьте его на наличие опечаток или отсутствующих символов. Когда синтаксис файла конфигурации будет правильным, перезагрузите Nginx для загрузки новой конфигурации:
Теперь Certbot сможет найти правильный серверный блок и автоматически обновлять его.
Теперь изменим настройки брандмауэра, чтобы он разрешал трафик HTTPS.
Шаг 3 — Доступ к HTTPS через брандмауэр
Если вы включили брандмауэр ufw в соответствии с предварительными требованиями, вам нужно будет настроить его так, чтобы разрешить трафик HTTPS. К счастью, при установке Nginx регистрирует в ufw несколько профилей.
Вы можете просмотреть текущие настройки с помощью следующей команды:
Возможно профиль будет выглядеть так, т. е. на веб-сервере будет разрешен только трафик HTTP:
Чтобы разрешить трафик HTTPS, активируйте профиль Nginx Full и удалите лишний профиль Nginx HTTP:
Теперь ваш статус должен выглядеть следующим образом:
Запустим Certbot и доставим наши сертификаты.
Шаг 4 — Получение сертификата SSL
Certbot предоставляет широкий выбор способов получения сертификатов SSL с помощью плагинов: Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется. Для использования этого плагина введите следующую команду:
Если это будет подтверждено, certbot запросит у вас предпочитаемый вариант настройки HTTPS:
Ваши сертификаты загружены, установлены и активированы. Попробуйте перезагрузить веб-сайт с помощью https:// и посмотрите на индикатор безопасности в браузере. Теперь в браузере должен отображаться символ замка, означающий, что сайт защищен надлежащим образом. Если вы протестируете свой сервер с помощью теста SSL Labs Server Test, он получит оценку A.
В заключение протестируем процесс обновления.
Шаг 5 — Проверка автоматического обновления Certbot
Сертификаты Let’s Encrypt действительны только в течение 90 дней. Это сделано для стимулирования пользователей к автоматизации процесса обновления сертификатов. Установленный нами пакет certbot выполняет это автоматически, добавляя таймер systemd, который будет запускаться два раза в день и автоматически продлевать все сертификаты, истекающиее менее, чем через 30 дней.
Вы можете запросить статус таймера с помощью команды systemctl :
Чтобы протестировать процесс обновления, можно сделать запуск «вхолостую» с помощью certbot :
Если ошибок нет, все нормально. Certbot будет продлевать ваши сертификаты, когда это потребуется, и перезагружать Nginx для активации изменений. Если процесс автоматического обновления когда-нибудь не выполнится, то Let’s Encrypt отправит сообщение на указанный вами адрес электронной почты с предупреждением о том, что срок действия сертификата подходит к концу.
Заключение
В этом обучающем модуле мы установили клиент certbot для Let’s Encrypt, загрузили сертификаты SSL для вашего домена, настроили Nginx для использования этих сертификатов и настроили автоматическое обновление сертификатов. Если у вас остались вопросы относительно использования Certbot, воспользуйтесь официальной документацией.
Let’s Encrypt и nginx: настройка в 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 лишь по острой необходимости. Более подробная документация тоже есть, но пока всю ее прочитаешь и найдешь всё то, что действительно нужно знать… К тому же, в ней не рассмотрены некоторые важные стратегические вопросы использования сертификатов.
Очевидно, нужна короткая и понятная инструкция для тех, кто привычен к серверной консоли, но хочет во всём разобраться без излишних трат времени.
Содержание
Из этой статьи вы узнаете.
Caveat emptor
В инструкциях ниже я исхожу из того что ваши сайты будут использовать 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?
Это просто. Вам не нужно постоянно держать в голове факты о выданных сертификатах. Для какого домена сертификат был выдан первым. К какому сертификату нужно добавлять еще домены. И так далее… Ни о чем таком со SNI не нужно думать.
Например, так можно посмотреть домены в сертификате Тематических Медиа:
На момент написания статьи эта команда выведет подробный список всевозможных доменов ТМ:
Никакой секретности и никаких тайн. Вы этого хотите?
Установка Certbot
Если вы читаете этот текст из будущего, когда Certbot уже есть в Debian stable и Ubuntu без обиняков и оговорок, то всё просто:
Либо используйте aptitude или другой пакетный менеджер вашего дистрибутива.
Установка в Jessie
Если у вас еще в ходу актуальный на конец 2016 года Debian stable «jessie», то всё лишь немного сложнее.
Нужно подключить Debian Backports, добавив строчку в /etc/apt/sources.list :
Теперь можно устанавливать с указанием источника:
(Раздел актуален пока только stretch не стал stable.)
Ubuntu версий ниже 16.10 (yakkety)
Другой дистрибутив
Если у вас какой-то другой дистрибутив, то дополнительные инструкции по установке есть на официальном сайте Certbot. Если обходиться без пакетного менеджера, то обычно установка сводится к.
Certbot и webroot
Мы будем получать сертификаты по методу webroot без перенастройки или остановки веб-сервера, под которым подразумевается nginx. Нам нужен какой-то каталог, в который certbot будет писать свои файлы, и какой должен быть доступен из сети удостоверяющему серверу согласно протокола ACME.
Чтобы не писать каждый раз длинную строку из опций, а еще лучше — не вспоминать о них, запишем основные настройки в файл конфигурации, который certbot ожидает найти в /etc/letsencrypt/cli.ini :
Последняя директива нужна чтобы избавить нас от прелестей и красивостей ncurses, что нужно чтобы вы могли сравнить вывод команд здесь, в этой статье, и у себя.
Также нам нужно мягко перезагрузить nginx (без перерыва в обслуживании) при успешном обновлении сертификатов. Ничего не мешает в этот же момент перезапускать и другие сервисы вроде Postfix, использующие полученные сертификаты. Команды указываются через точку с запятой.
Если вы видите такую ошибку:
Что будет делать Certbot
Ожидается что certbot будет создавать необходимые для проверки прав на домен файлы в подкаталогах ниже по иерархии к указанному. Вроде таких:
Эти файлы должны будут быть доступны из сети на целевом домене по крайней мере по HTTP:
Для следующих проверок создадим какой-то такой файл:
Регистрация в Let’s Encrypt
Регистрацию нужно сделать только один раз:
Здесь ничего сложного.
Подготовим nginx к получению сертификатов
В общем случае для получения сертификата необходимо во всех блоках server добавить следующий блок до других блоков location :
Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл /etc/nginx/acme с содержанием блока выше.
Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем:
Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию. Подробней об этом ниже.
Перезагрузим nginx и проверим что наш тестовый файл виден:
После проверки лучше удалить тестовый файл — certbot любит удалять за собой всё лишнее, а такой файл будет мешать и вызывать сообщение об ошибке (Unable to clean up challenge directory).
О переадресации с кодами 301 и 302
Как было уже сказано, ACME сервер Boulder учитывает переадресацию с кодами 301 и 302. В этом смысле не имеет значения где, в конечном счете, находятся файлы, требуемые для прохождения проверок. Переадресация возможна даже на нестандартные порты, без ограничений по конечному протоколу HTTP или HTTPS. Сами Let’s Encrypt рекомендуют использовать переадресацию для создания единой точки проверки прав на домены.
Если вы можете получить эти файлы с помощью curl с ограничением в десять переадресаций, то и Boulder эти файлы увидит. Не должно быть никаких ограничений по IP адресам.
Это удобно если у вас сложная структура переадресаций между разными версиями сайтов. Должно быть достаточно подключить тот блок с location только на основном сайте для получения сертификатов для всех остальных.
Проверка всегда начинается с запроса по протоколу HTTP на 80 порту.
Если у вас уже всё зашифровано.
Другое дело что можно сократить путь и подключить наш блок с location в умолчальном сервере для 80 порта, который делает переадресацию на HTTPS. Тогда не нужно будет ничего дописывать в конфиги отдельных сайтов.
Пример конфигурации такого переадресующего всё-подряд-на-HTTPS сервера:
Сервер запускаем явно на внешнем IP чтобы не перенастраивать Apache на другой порт. Если для вас это не проблема, то указание имени сервера в директиве listen можно пропустить.
Если нужно получить сертификат для домена без сайта.
Типичный пример — сертификат для выделенных под SMTP или IMAP серверов, на которых вообще нет каких-то сайтов. Либо используйте универсальный переадресатор что выше, либо.
К сожалению, протокол ACME требует чтобы такой сервер был доступен во время каждой проверки. Это практически эквивалентно постоянной доступности, ввиду требования получения и обновления сертификатов без перезагрузки сервера. Не удаляйте такой конфиг после получения сертификата.
Если у вас только Apache2.
Если у вас Apache2, а перейти на всеми любимый nginx возможности нет, то… Добавьте следующие строчки в /etc/apache2/conf-available/certbot.conf :
И обязательно проверьте, так:
Существует много причин почему такая схема может у вас в Apache2 не заработать. Пары экранов текста не хватит чтобы описать их все. Не серчайте — статья про nginx.
Получаем сертификаты
У Let’s Encrypt есть лимиты на количество обращений за сертификатами, потому сначала попробуем получить необходимый сертификат в режиме для тестов:
В конце программа должна отчитаться об успешной работе:
Теперь можно смело получать сертификат уже в самом деле. Не забудьте явно указать все необходимые поддомены, такие как www.
Ура! С получением сертификата закончено!
Если нужно добавить поддомен или домен в сертификат
Вам будет безальтернативно предложено добавить этот домен в сертификат. Если хочется избежать вопросов, то можно сразу указать одобряющий такое поведение ключ:
Операцию можно повторять.
Проверим полученный сертификат
Убедимся что полученный сертификат — именно тот, что нам нужен:
Или, если подробности вам не нужны:
Команда должна вывести список доменов в сертификате.
Установка и использование сертификатов
Certbot не перезаписывает сертификаты, а заменяет их ссылками на самые актуальные варианты сертификатов в определенном каталоге, одноименном с первым доменом сертификата (т.е. CN ).
Давайте посмотрим что за файлы у нас есть:
С этим знанием мы можем задать настройки SSL для nginx:
Как видите, cert.pem нигде в конфиге не используется, и это не ошибка. Для nginx он не нужен.
Полный рабочий пример конфига:
Конфиг для переадресации с голого домена без www:
Подразумевается что вы используете какой-то локальный сервер для кеширования DNS запросов. Если это не так, то 127.0.0.1 в директиве resolver нужно заменить на IP используемого DNS сервера.
Perfect Forward Secrecy
Если вы переживаете что Certbot может утащить ключи от вашего сертификата не смотря на открытые исходные коды, а значит, в теории, какие-то злодеи смогут расшифровать весь трафик, то спешу вас успокоить. Если для соединения с вашим сайтом используются шифры из семейств DHE и ECDHE, то утечка ключа не позволит расшифровать трафик. В этих шифрах ключ сертификата используется только для подтверждения подлинности, и не используется в качестве ключа для шифрования. Все современные браузеры поддерживают эти шифры.
Если для ECDHE на эллиптических кривых ничего не нужно делать, то для DHE можно было бы использовать усиленные параметры. Лучше всего будет отключить DHE вообще.
Если по какой-то причине без DHE вы не можете обойтись, то сначала создадим параметры:
Потом пропишем в /etc/nginx/conf.d/ssl_dhparam.conf одной строкой:
Продление сертификатов
Сертификаты выдаются на три месяца. Не на полгода, не на год, а лишь на три месяца. Естественно это вызывает вопросы. Нужно ли проходить всю эту процедуру через три месяца? Нужно ли это делать всегда до искончания веков? Может стоит всё-таки вложиться в платный сертификат чтобы забыть об этом всем и не воспоминать пару лет?
Но нет, не спешите искать платежные средства! Как и было обещано в начале статьи, с обновлением сертификатов проблем нет.
Если у вас Debian и systemd, то посмотрите эти инструкции.
Как это работает
Например, были у вас на сервере были сайты www.example.com и shop.example.com, проходящие под одним сертификатом, но потом вы перенесли shop.example.com на другой сервер. Если такой ключ не указать, то Certbot упадет с ошибкой при попытке подтвердить владение shop.example.com, не получив для вас вообще никакого сертификата. Сертификат истечет и ваш сайт уйдет в оффлайн. С этим ключом вы всё же получите сертификаты хотя бы для частичного набора доменов, оставив ваши сайты в сети.