Исправление ошибок Let’s Encrypt
General | Комментировать запись
При настройке домена или поддержки HTTPS могут возникать разные ошибки. Устранять неполадки в DNS (Domain Name System) сложно; кроме того, трудно также достоверно определить ошибки DNS, так как они могут быть вызваны другой частью стека.
Наверняка вы раньше встречали это печально известное хайку:
It’s not DNS
There’s no way it’s DNS
It was DNS
Чаще всего проблемы с DNS возникают при настройке на серверах поддержки SSL/HTTPS (например Let’s Encrypt). В этом туториале мы рассмотрим некоторые распространенные ошибки, с которыми вы можете столкнуться при работе с DNS, HTTPS или Let’s Encrypt. Приведенные здесь советы применимы независимо от вашего провайдера DNS.
DNS-записи
DNS — это система, которая присваивает и направляет трафик на серверы с помощью доменных имен (например your_domain.com) вместо того, чтобы привязывать все к IP. Все регистраторы доменов предоставляют собственный интерфейс для управления записями DNS, у них похожий синтаксис и правила.
Читайте также: Введение в DNS: основные термины, компоненты и понятия
Самая распространенная запись DNS — запись A, это связь между доменом и адресом сервера. В этом мануале и при присвоении канонических доменов IP-адресам серверов мы будем работать в основном с записями A.
Обновление или миграция DNS-записей
Внесение обновлений в DNS может занять некоторое время. Обычно это занимает менее получаса, но поскольку вы не можете протестировать DNS сразу после внесения изменений, то ошибки всплывают со временем, а это может вас запутать. Вы сможете настроить LetsEncrypt для своего домена только после того, как изменения DNS распространятся на большинство или все глобальные серверы имен.
С помощью сайта whatsmydns.net можно проверить, обновился ли DNS на большинстве или на всех серверах глобальных имен. Если DNS не разрешается для вас локально, нужно проверить, может ли он работать в большинстве мест. Ваш интернет-провайдер может обновлять информацию медленнее, чем другие, но в большинстве случаев это займет всего несколько минут.
Если вы проводите тестирование в течение короткого промежутка времени, когда изменения DNS распространились только на часть серверов, то, возможно, вы получите разные результаты с удаленного сервера и с локального браузера, а это еще больше сбивает с толку. Такое может произойти, если DNS удаленного сервера обновился раньше, чем DNS провайдера. Чтобы исключить эти ошибки, можно с помощью команды nslookup проверить, на какой IP разрешается конкретный домен:
nslookup 8host.com
… Name: 8host.com Addresses: 2606:4700::6810:b50f 2606:4700::6810:b60f 104.16.181.15 104.16.182.15
Таким образом, вы можете проверить, совпадают ли локальные результаты с глобальными DNS-резолверами.
Используя в настройке DNS более продолжительное значение TTL (Time-To-Live), вы также увеличите время обновления. Значение TTL по умолчанию, которое поддерживает большинство регистраторов доменов — 3600 секунд (1 час). Обычно это значение указано рядом с записью A. Длительное значение TTL помогает эффективнее кэшировать запросы, но может увеличить время обновления DNS. Если вы планируете вносить или тестировать изменения DNS, возможно, стоит временно уменьшить значение TTL.
Ошибки браузера и проблемы с конфигурацией HTTPS
Иногда бывают ситуации, когда HTTPS и DNS вроде бы настроены правильно, но вы или ваши пользователи при попытке входа на сайт все еще получаете ошибки в браузере.
Ознакомьтесь с гайдом Коды ошибок HTTP: расшифровка и устранение. Большинство из них не будут напрямую указывать на ошибки HTTPS, но они могут быть результатом неправильной настройки. Например, вы можете получить ошибку 502, если вы используете обратный прокси-сервер Nginx для шлюза HTTPS другого работающего на сервере приложения и этот шлюз неправильно настроен.
Еще одна ошибка, с которой вы можете столкнуться — просроченный сертификат. В отличие от коммерческих сертификатов HTTPS, сертификаты LetsEncrypt действительны только в течении 3 месяцев, и если не обновить сертификат до истечения срока его действия, то у всех, кто пытается получить доступ к вашему сайту, возникнет ошибка.
Обычно это ERR_CERT_DATE_INVALID. В Chrome это может выглядеть так:
При первой настройке LetsEncrypt создает фоновый процесс автоматического обновления сертификата. Также LetsEncrypt обычно отправляет имейл, когда срок действия сертификата подходит к концу.
Но если этот процесс неправильно настроен или не запускается, вы всегда можете обновить сертификаты вручную, повторно запустив certbot с аргументом renew:
sudo certbot renew --nginx -d example.com -d www.example.com
Возможно, после обновления сертификатов потребуется перезапустить сервер. Если вы не вносили никаких других изменений в конфигурацию, вы можете спокойно автоматизировать этот процесс (например, добавить его в cron). Для этого после обновления сертификата запустите команду systemctl restart nginx.
Ошибки “mixed content”
Если вы переносите сложный стек с HTTP на HTTPS, вы можете заметить, что некоторые изображения или другие ресурсы сайта не отображаются. Если вы откроете консоль разработчика в браузере, то увидите, что эти ошибки относятся к “mixed content”:
Это связано с веб-политикой по умолчанию, согласно которой HTTP-контент не должен включаться в обслуживаемые по HTTPS сайты. Это может произойти, когда один сайт загружает данные с двух разных серверов или когда приложение обслуживается за шлюзом Nginx, но переадресация SSL работает неправильно.
Если вы с помощью Nginx перенаправляете трафик в другое приложение и сталкиваетесь с предупреждениями mixed content, можете попробовать добавить дополнительную конфигурацию переадресации SSL в location block:
… location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Proto https; }
Также убедитесь, что все обслуживаемые сайты настроены на HTTPS. Рекомендуем ознакомиться с материалами MDN по ошибкам mixed content.
Ошибки при запуске скрипта Certbot
Вы также можете столкнуться с ошибками при запуске скрипта Let’sEncrypt certbot. Иногда эти ошибки имеют подробный вывод, который можно разобрать. Другие могут быть не совсем понятными. Если скрипт превышает время ожидания, то, скорее всего, проблема с брандмауэром:
certbot --nginx -d example.com -d www.example.com
Press Enter to Continue Waiting for verification… Cleaning up challenges Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://example.com/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0: 93 Timeout during connect (likely firewall problem)
Обычно timeout вызван тем, что соединение не может получить ни сам ответ, ни подтверждение об отказе, потому что брандмауэр сбрасывает весь трафик. Прежде чем пытаться запустить certbot, убедитесь, что брандмауэр не блокирует порт 80 или 443. В некоторых материалах указывается, что вам нужно открыть только один из портов (80 или 443), но чтобы исключить любые ошибки, попробуйте открыть оба. Если вы используете UFW с Nginx, включите профиль Nginx Full:
sudo ufw allow 'Nginx Full'
Попробуйте перезапустить certbot после изменения конфигурации брандмауэра. Если вы перезапустили certbot несколько раз подряд, вы можете получить “failed validation limit”:
too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/
В этом случае вам придется подождать до часа, пока с учетной записи будут сняты ограничения. Дополнительные сведения о validation limit и других ошибках клиента см. в документации Certbot.
Если вы получаете какие-то другие ошибки certbot, которые не связаны с DNS, timeout или проблемами с соединением, то они, скорее всего, связаны со средой Python на сервере, которая была настроена certbot.
Эти проблемы почти всегда решаются переустановкой certbot. Для этого выполните пункт 1 мануала Создание сертификата Let’s Encrypt для Nginx. Это не повлияет на конфигурацию HTTPS, а только на утилиты обслуживания и обновления.
HTTPS не работает без видимых ошибок
Если вы убедились, что Certbot и DNS работают правильно, но ваш сайт не переключился с HTTP на HTTPS, обычно это проблема с конфигурацией сервера. При первом запуске Certbot пытается автоматически обновить файлы конфигурации сервера. Именно поэтому в команде Certbot обычно указывается nginx, чтобы он знал, какую конфигурацию сервера обновлять после получения сертификата. Но если конфигурация сервера очень сложная, у Certbot может не получиться обновить ее для разрешения HTTPS и вам придется вносить изменения вручную.
Во-первых, убедитесь, что вы включили блок server_name в файл конфигурации сервера, как описано в пункте 2 этого мануала. Без этого certbot не будет знать, какой файл конфигурации нужно обновить. Если после этого у вас все еще возникают проблемы, то, чтобы получить только сертификат, вам может понадобиться запустить certbot в автономном режиме (standalone mode), а затем вручную настроить сервер на использование HTTPS.
Базовая конфигурация Nginx HTTPS будет включать listen 443 ssl, путь к сертификату SSL и ключу:
… listen 443 ssl; # RSA certificate ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem; # Redirect non-https traffic to https if ($scheme != "https") { return 301 https://$host$request_uri; } …
Помните, если вы настраиваете Nginx, перед перезапуском сервера, вы можете проверить любые изменения в конфигурации Nginx с помощью nginx -t. Когда вы закончите вносить изменения, вы можете перезапустить Nginx с новой конфигурацией, выполнив systemctl restart nginx:
sudo systemctl restart nginx
Подводим итоги
Цель LetsEncrypt — предоставить бесплатный HTTPS всем, кому это нужно. Когда все работает автоматически — это очень удобно, но когда нет — могут возникнуть трудности, особенно если у вас мало опыта настройки SSL или DNS. В этом туториале мы рассмотрели несколько распространенных ошибок для LetsEncrypt, а также способы устранения этих неполадок.
Tags: DNS, HTTP, HTTPS, Let's Encrypt, SSL