☰

一个域名的多域名证书失败

tag-icon • tag-icon nginx ssl-certificate lets-encrypt
一个域名的多域名证书失败

我一直在使用 letsencrypt SSL 证书托管一些 nginx 服务器。

  • domain-a.org 位于服务器 1 上，拥有自己的证书。
  • sub.domain-a.org 在服务器 2 上，有自己的证书

起初，服务器 2 仅用于 sub.domain-a.org，后来我将其设为多域证书，该证书也适用于 sub.domain-b.org。但是，domain-b.org 是我的客户的网站。我已向他们的 DNS 添加了 A 记录和 CNAME，以将 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（我可以控制）使用了 SSL 证书？但我不明白这会不会是个问题，因为我有子域名的证书……

编辑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;

答案1

Firefox 已警告称，混合内容（HTTP 和 HTTPS）的页面一段时间内不受信任，在某些平台上，除非您接受风险，否则现在不会显示页面。检查您的网站是否显示混合内容，您可以通过查看页面源代码或在开发人员工具 (F12) 中加载页面来检查。您还可以通过单击 Chrome 和 Firefox 中位置字段中挂锁旁边的“i”图标来检查证书的状态。

答案2

好奇。自签名证书的创建日期是 2018 年 5 月 6 日星期日。

  1. 检查您的 DNS。运行dig +noall +answer sub.domain-a.org sub.domain-b.org并检查两个域是否指向同一服务器。似乎您无法控制domain-b.org，因此您的客户端可能已更改其 DNS 配置。
  2. 检查你的 nginx 配置，如果有任何server阻止服务sub.domain-b.org和default_server，则可能是罪魁祸首；但似乎你之前没有更改过任何 nginx 配置，所以我对此表示怀疑。
  3. 检查您的证书。运行openssl x509 -in /path/to/certificate/public_key.pem -noout -text并/path/to/certificate/public_key.pem指向 中的证书snippet/ssl.conf。检查证书的颁发者。

答案3

由于我没有在服务器端发现任何问题，我联系了 domain-b.org 的托管提供商。幸运的是，他们很快就回复了我，并告诉我他们最近将控制面板从旧系统迁移到了 Plesk。出于某种原因，他们无法告诉我，但他们确实不是迁移任何子域。因此，我在他们的旧面板中检查了我的 DNS 配置，结果显示一切正常，但事实并非如此。

mforsetti 在他的回答中给出的第一个命令也证实了这一点：sub.domain-b.org 指向托管提供商的服务器。我从来没有想过要进行 DNS 查找，因为我确信 DNS 记录就在我面前老的控制板。

我现在正尝试访问他们的 Plesk 面板，只需再次添加 A 记录即可解决问题。

相关内容