#Что происходит и когда применима инструкция
Имя *.example.com покрывает одноступенчатые поддомены наподобие www.example.com, но само example.com в него не входит. Для корневого имени нужен отдельный SAN в том же сертификате или отдельный сертификат.
#Причины: как различить похожие случаи
| Возможная причина | Как узнать | Что делать |
|---|---|---|
Отсутствует корневое имя в SANWildcard-сертификат выдан только для *.example.com. | Проверка Subject Alternative Name показывает wildcard, но не DNS:example.com. | Добавить корневое имя в сертификат или назначить отдельный сертификат. |
| Nginx использует старый сертификатНовый выпуск уже включает apex, но веб-сервер отдаёт другой файл. | certbot certificates и сертификат по TLS отличаются по списку имён. | Проверить ssl_certificate для нужного server и reload после теста. |
| Другая точка завершает HTTPSБалансировщик или CDN отдаёт сертификат раньше Nginx. | Сертификат на прямом IP и публичный сертификат отличаются. | Обновить сертификат на внешнем узле, не только на сервере сайта. |
#Диагностика и пошаговое устранение
- 1. Уточните, какое имя выдаёт предупреждениеОткройте сайт отдельно по
https://example.comиhttps://www.example.com(заменив домен). Если поддомен работает, а корень не проходит проверку имени, очень вероятно отсутствие apex в сертификате. Не выбирайте кнопку игнорирования ошибки TLS: это мешает понять реальную причину.
- 2. Просмотрите имена сертификата у посетителяВ Linux-терминале выполните команду для публичного сервера; SNI задаётся параметром
-servername,-connectуказывает адрес и порт. По выходу найдитеX509v3 Subject Alternative Name, список DNS и даты. Если оболочка не позволяет открыть соединение, выполните проверку с другого компьютера либо через браузерную информацию о сертификате. - Дополнительная команда по темеLinux · Терминал (Bash)КомандаЗамените example.com своим доменом; без прав администратора; команда лишь читает предъявленный сертификат.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -ext subjectAltName -dates
- 3. Проверьте заявку и автоматическое продлениеЕсли используется Certbot, по SSH запросите список сохранённых сертификатов. Сравните Domains и Certificate Path с предъявляемым сервером. Если в Domains только
*.example.com, проблема не в браузере; необходимо запросить оба имени. Если используется панель, откройте карточку сертификата и проверьте перечень доменов до смены конфигурации.Linux · Терминал (Bash)КомандаНужен sudoТолько чтение списка сертификатов Certbot; не требуется, если сертификаты выпускает панель.sudo certbot certificates
- 4. Выберите способ покрытия обоих имёнДля единого сертификата нужен набор
-d example.com -d "*.example.com"при выдаче методом DNS-01: HTTP-01 не подтверждает wildcard. При ручном DNS-01 учтите, что для этих имён могут потребоваться два разных TXT-значения в_acme-challenge.example.comодновременно. Не копируйте предложенные здесь примерные домены; уточните действующий DNS-плагин и дождитесь его штатного подтверждения.
- 5. Сохраните действующие файлы и запросите обновление штатноПеред перевыпуском выпишите имя сертификата (
Certificate Name), путьfullchain.pem, путь закрытого ключа и сохраните рабочую конфигурацию сайта, не передавая ключ третьим лицам. В Certbot используйте его документированный механизм--cert-nameи полный набор-dдля обновления существующего сертификата; способ аутентификации DNS должен уже быть настроен. Не выполняйте массовые повторные выдачи и не удаляйте старый сертификат.
- 6. Проверьте, что Nginx использует сертификат с SAN apexПо SSH прочитайте блок
serverдляexample.comи директивыssl_certificate,ssl_certificate_key. В Nginx для Let’s Encrypt обычно указываютfullchain.pem, а неcert.pem; файл ключа не следует выводить на экран или копировать в публичную директорию. При изменении конфигурации сначала сохраните копию и выполните проверку синтаксиса.Linux · Терминал (Bash)КомандаНужен sudoТолько тест конфигурации Nginx; после успешного теста отдельно примените reload по регламенту.sudo nginx -t
- 7. Примените сертификат на правильном узлеЕсли TLS завершается на сервере, после успешного теста примените
sudo systemctl reload nginx; действующие подключения обычно не обрываются. Если впереди находится CDN, панель управления или балансировщик, обновите сертификат именно там и затем перепроверьте публичный доступ. Не меняйте одновременно настройки нескольких узлов без фиксации исходного состояния.Linux · Терминал (Bash)С осторожностьюНужен sudoПрименить только послеnginx -t, если конфигурация корректна.sudo systemctl reload nginxКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 8. Проверьте корень, поддомен и продлениеПовторите TLS-проверку для
example.comиwww.example.com. В обоих случаях должен предъявляться сертификат, SAN которого покрывает проверяемое имя, срок действия не истёк. Уточните, что плановая автоматическая выдача сохраняет оба имени. Если имя всё ещё отсутствует — сервер отдаёт не тот файл или внешний узел не обновлён.
#Как проверить, что неисправность устранена
Проверяйте именно открытие корневого имени и наличие DNS:example.com в SAN публичного сертификата, а не только наличие файла в /etc/letsencrypt. Отдельно проверьте обычный поддомен.
#Если не получилось и как отменить правки
При ошибочном подключении сертификата верните прежнюю директиву ssl_certificate из копии конфигурации, выполните nginx -t и reload. Старый сертификат не отменяет требования покрыть apex; если необходимо срочно восстановить корень, назначьте ранее действующий корректный сертификат.
Если причина не установлена, соберите точный текст ошибки, время, имя домена, результаты проверок без паролей и приватных ключей. Передайте их ответственному администратору или поддержке регистратора, DNS-провайдера либо хостинга. Не повторяйте опасные изменения без резервной копии.