Если вы управляете Linux-сервером, скорее всего, вам известно, что Let’s Encrypt — это бесплатный, автоматизированный и открытый центр сертификации (CA), который предоставляет TLS-сертификаты с проверкой домена, что позволяет активировать HTTPS на вашем сайте или веб-приложении без дополнительных расходов.
Ранее мы рассматривали корректный процесс получения и установки TLS-сертификата от Let’s Encrypt.
- Как настроить HTTPS на Nginx с использованием Let’s Encrypt в Ubuntu
- Как настроить HTTPS на Apache с использованием Let’s Encrypt на Ubuntu
Однако, как это часто бывает в Linux, могут возникнуть непредвиденные ошибки, и в данной статье будут даны рекомендации по их устранению.
Содержание статьи
Установите самую актуальную версию Certbot.
Всегда рекомендуется пользоваться самой актуальной версией Certbot. При возникновении ошибки она предоставляет более подробные сообщения, что облегчает процесс поиска решения. В некоторых случаях обновление до последней версии Certbot может само по себе устранить проблему.
Вы можете установить самую последнюю версию с помощью Snap.
sudo snap install certbot --classic
После этого используйте исполняемый файл /snap/bin/certbot вместо обычного /usr/bin/certbot.
sudo /snap/bin/certbot --webroot --agree-tos --redirect --hsts --staple-ocsp - d example.com
Вы можете установить символическую ссылку с помощью следующей команды, чтобы при вводе
certbot
в терминале автоматически запускалась версия, установленная через Snap.
sudo ln - sf /snap/bin/certbot /usr/bin/certbot
Чтобы узнать больше о Snap-пакетах и о том, как активировать Snap на разных дистрибутивах Linux, ознакомьтесь с данной статьей.
- Как установить и применять Snap-пакеты в Linux
Применяйте плагин Webroot.
Вы можете заменить плагины Apache или Nginx на плагин Webroot для получения сертификатов TLS. Я заметил, что он работает более стабильно и реже вызывает ошибки.
Вместо того, чтобы выполнять данную команду:
sudo /snap/bin/certbot --nginx --agree-tos --redirect --hsts --staple-ocsp - d example.com
sudo /snap/bin/certbot --webroot --agree-tos --redirect --hsts --staple-ocsp - d example.com - w /var/www/html
Флаг — w определяет веб-каталог вашего сайта или веб-приложения. В вышеуказанном примере указан путь /var/www/html/. Чтобы узнать точное местоположение, обратитесь к конфигурационному файлу вашего веб-сервера.
В Apache должна присутствовать строка, аналогичная следующей:
DocumentRoot "/var/www/nextcloud"
В конфигурации Nginx должна присутствовать строка подобного вида:
root /var/www/nextcloud/;
Прерывание соединения (возможно, причина кроется в файрволе)
Некоторые пользователи могут натолкнуться на следующую проблему:
IMPORTANT NOTES: - The following errors were reported by the server: Domain: mail.example.com Type: connection Detail: Fetching http://mail.example.com/.well-known/acme-challenge/8aNsZkYzpbFXyWUAECaJEj1eBsVhPOokDYeNTgw4nq8: Timeout during connect (likely firewall problem) To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided. Can't open /etc/letsencrypt/renewal/mail.example.com.conf: No such file or directory.
Это может быть обусловлено:
- Ошибка в записи DNS A. Вы указали неверный IP-адрес для mail.example.com? Не следует использовать частный IP-адрес в записи DNS A. Для этого требуется указать публичный IP-адрес.
- Запись DNS еще не была распространена. Вы можете проверить её распространение, посетив https://dnsmap.io.
- TCP-порты 80 и 443 не были открыты в вашем брандмауэре. Чтобы Certbot мог выполнить проверку HTTP-01, ему нужен доступ к определенной веб-странице, поэтому важно открыть эти порты. Если вы работаете с UFW, ознакомьтесь с этим руководством: Как использовать брандмауэр UFW в Debian, Ubuntu, Linux Mint.
Настройки Nginx не применяются.
Некоторые пользователи могут оказаться в ситуации, когда возникает эта ошибка:
Подсказка: Центр сертификации не смог подтвердить временные изменения конфигурации nginx, внесенные Certbot. Убедитесь, что указанные домены указывают на этот сервер nginx и что он доступен из интернета.
Это говорит о том, что файл вашего виртуального хоста не был загружен в Nginx. Нужно выполнить перезагрузку Nginx.
sudo systemctl restart nginx
Иногда в конфигурационном файле Nginx могут возникнуть ошибки. Чтобы их проверить, выполните следующую команду.
sudo nginx - t
Кроме того, не забудьте просмотреть журнал Nginx.
sudo journalctl - eu nginx
Однажды я столкнулся с проблемой из-за того, что не указал директиву server_name в конфигурационном файле Nginx. В результате Nginx не смог определить, какой конфигурационный файл применять для запроса Certbot.
Пример уведомления об ошибке:
ВАЖНЫЕ ЗАМЕЧАНИЯ: - Сервер сообщил об ошибках: Домен: onlyoffice. linux16.ru Тип: unauthorized Подробности: 2606:4700:20::681a:c47: Неверный ответ от https://onlyoffice. linux16.ru/.well-known/acme-challenge/piqJOZM3CYsCGAmT-ZdfKI2XrvteQQEyKgtIHM6DNo4: 526 Чтобы исправить эти ошибки, убедитесь, что имя домена было введено правильно, и что записи DNS A/AAAA для этого домена содержат правильный IP-адрес.
Как правило, чтобы понять причину этой ошибки, необходимо изучить журнал ошибок вашего веб-сервера. Например, я столкнулся с этой проблемой, когда пытался получить сертификат TLS для OnlyOffice. В журнале ошибок веб-сервера Nginx можно было увидеть следующие записи.
022/12/01 04:53:23 [error] 26124#26124: *14 open() "/var/www/onlyoffice/documentserver/letsencrypt/.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA" не удалось (2: Нет такого файла или каталога), клиент: 127.0.0.1, сервер: webmail.sk8deal.com, запрос: "GET /.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA HTTP/1.1", хост: "onlyoffice. linux16.ru", источник: "http://onlyoffice. linux16.ru/.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA"
По этой причине мне необходимо организовать каталог для протокола ACME от Let’s Encrypt.
sudo mkdir - p /var/www/onlyoffice/documentserver/letsencrypt/.well-known/acme-challenge/
Смените собственника на www-data.
sudo chown www-data:www-data /var/www/onlyoffice/documentserver/letsencrypt/ - R
Попробуйте сгенерировать файл под учетной записью пользователя www-data.
sudo - u www-data touch /var/www/onlyoffice/documentserver/letsencrypt/.well-known/acme-challenge/uhV7Py-ruxoDSkY_BcZwiifQ1L_Pli6pMK0wvInNiLA
Если все прошло успешно, вы можете повторно запустить certbot для получения TLS-сертификата. В случае появления ошибки «доступ запрещен» необходимо предоставить права пользователю www-data.
sudo apt install acl sudo setfacl - R - m u:www-data:rxx /var/www/onlyoffice/
Тестовый запуск
Если в течение определенного времени было слишком много неудачных попыток получить TLS-сертификат от Let’s Encrypt, то, вероятно, дальнейшие запросы к серверу Let’s Encrypt CA будут отклонены. Чтобы этого избежать, рекомендуется использовать флаг —dry-run для проверки.
sudo /snap/bin/certbot certonly --dry-run --webroot --agree-tos --redirect --hsts --staple-ocsp - d example.com - w /var/www/html
Тестовый режим функционирует исключительно с подкомандой certonly, поэтому их необходимо применять совместно. После устранения ошибки и успешного завершения тестирования, вы сможете получить TLS-сертификат.
sudo /snap/bin/certbot --webroot --agree-tos --redirect --hsts --staple-ocsp - d example.com - w /var/www/html
Заключение
Надеюсь, этот гид был полезен для работы с certbot. Если вам понравилась статья, подписывайтесь на нашу бесплатную рассылку, чтобы получать больше полезных советов и рекомендаций.