Я размещал несколько серверов nginx с SSL-сертификатами letsencrypt.
Сначала сервер 2 предназначался только для sub.domain-a.org, а позже я сделал его многодоменным сертификатом, который также был действителен для sub.domain-b.org. Однако domain-b.org - это веб-сайт моего клиента. Я добавил запись A и CNAME в их DNS, чтобы указать sub.domain-b.org на мой сервер 2.
Эта ситуация работала нормально в течение нескольких месяцев и внезапно сломалась. На прошлой неделе сайт sub.domain-b.org по какой-то причине перестал работать в Firefox. sub.domain-a.org на тот момент все еще работал безупречно. После публикации этого вопроса сегодня я заметил, что он также перестал работать в Chrome. По крайней мере, сейчас это одинаково среди браузеров ...
Когда я использую https://www.ssllabs.com/ чтобы найти сертификат sub.domain-b.org, я получаю следующее:
сертификат не доверяет
Похоже, он каким-то образом возвращает самоподписанный сертификат.
Если я попробую то же самое для sub.domain-a.org, все будет хорошо, и я получу рейтинг A +. Пробуем то же самое, используя https://www.sslchecker.com/sslchecker не дает никакого результата для sub.domain-b.org.
Я действительно в растерянности и не понимаю, почему это не работает для одного из двух доменов, а для другого. Может быть, это потому, что domain-b.org (который я не контролирую) не использует сертификат SSL, а domain-a.org (который я контролирую) использует? Я не понимаю, как это может быть проблемой, поскольку у меня есть сертификат для поддомена ...
Редактировать 1 Я отредактировал свой вопрос. Первоначально он сказал, что sub.domain-b.org не работает только с Firefox, что и было несколько минут назад. Теперь это не работает ни в одном браузере. Safari также четко заявляет, что сертификат является самозаверяющим, а Chrome и Firefox вообще не показывают сертификат.
Редактировать 2 Добавление конфигурации nginx:
# upstream for backend application
upstream backend {
server 127.0.0.1:8080;
}
# Default server configuration
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name sub.domain-a.org www.sub.domain-a.org;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl.conf;
include snippets/ssl-params.conf;
root /var/www/domain-a/html/dist;
index index.html index.htm;
location ~ /.well-known {
allow all;
}
# Proxy ws with upgrade to websockets
location /rest/ws {
# websocket stuff
}
# Proxy calls to /rest to the backend application
location ^~ /rest {
proxy_pass http://backend/rest;
}
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
}
ssl-params.conf:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
Я связался с хостинг-провайдером domain-b.org, так как не смог найти никаких проблем на стороне моего сервера. К счастью, они быстро ответили и сказали мне, что недавно перенесли свою панель управления со старой системы на Plesk. По какой-то причине они не могли мне сказать, они сказали не переносить любые поддомены. Итак, я проверял свою конфигурацию DNS на их старой панели, которая показывала, что все в порядке, хотя это не так.
Первая команда, которую дал mforsetti в своем ответе, также подтверждает это: sub.domain-b.org указывал на сервер хостинг-провайдера. Я никогда не думал о поиске DNS, потому что был убежден, что у меня есть записи DNS прямо передо мной в их старый панель.
Я пытаюсь получить доступ к их панели Plesk сейчас, и это будет исправлено простым добавлением записи A.
Любопытно. Дата создания самозаверяющего сертификата - воскресенье, 6 мая 2018 г.
dig +noall +answer sub.domain-a.org sub.domain-b.org
и проверьте, указывают ли оба домена на один и тот же сервер. Кажется, ты не контролируешь domain-b.org
, так что, вероятно, ваш клиент изменил свою конфигурацию DNS.server
блокировка обслуживания sub.domain-b.org
и default_server
, это могло быть виновником; но похоже, что вы раньше не меняли ни одну из своих конфигураций nginx, поэтому я сомневаюсь в этом.openssl x509 -in /path/to/certificate/public_key.pem -noout -text
с участием /path/to/certificate/public_key.pem
указывает на ваш сертификат в snippet/ssl.conf
. Проверьте издателя сертификата.Firefox предупредил, что страницы со смешанным содержимым (HTTP и HTTPS) некоторое время не являются доверенными, и на некоторых платформах теперь не отображаются страницы, если вы не принимаете на себя риск. Убедитесь, что на ваших сайтах не отображается смешанный контент, что вы можете сделать, просмотрев источник страницы или загрузив страницу в Инструментах разработчика (F12). Вы также можете проверить статус сертификата, щелкнув значок «i» рядом с замком в поле местоположения как в Chrome, так и в Firefox.