Multi-domain certificate failing for one domain

Question

I've been hosting some nginx servers with letsencrypt SSL certificates.

• domain-a.org is on server 1 with it's own certificate.
• sub.domain-a.org is on server 2 with it's own certificate

At first server 2 was for only sub.domain-a.org and later on I made it a multi-domain certificate which was also valid for sub.domain-b.org. domain-b.org however is the website of a client of mine. I've added an A record and a CNAME to their DNS to point sub.domain-b.org to my server 2.

This situation has been working fine for months and all of a sudden it broke down. For some reason the website sub.domain-b.org stopped working on Firefox last week. sub.domain-a.org was still working flawlessly on both at that point. After posting this question today I noticed it also stopped working in Chrome now. At least it's consistent among browsers now...

When I use https://www.ssllabs.com/ to lookup the certificate of sub.domain-b.org I get the following:

certificate not trusted

This looks like it is somehow returning a self-signed certificate.

If I try the same for sub.domain-a.org all is good and I get an A+ rating. Trying the same thing using https://www.sslchecker.com/sslchecker yields no result at all for sub.domain-b.org.

I'm really at a loss here and don't understand why this isn't working for one of the two domains but it is for the other. Could this be because the domain-b.org (which I don't control) is not using an SSL certificate, while domain-a.org (which I do control) does? I don't see how that could be an issue though, since I have a certificate for the subdomain...

Edit 1 I edited my question. It originally said sub.domain-b.org was not working on Firefox only, which was the case, until moments ago. Now it's not work on any browser. Safari also clearly states that the certificate is a self-signed one, while Chrome and Firefox are not showing a certificate at all.

Edit 2 Adding nginx config:

# 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;

Answer 1

Firefox has warned that pages with mixed content (HTTP and HTTPS) are untrusted for some time and on some platforms is now not displaying pages unless you accept the risk. Check that your sites are not showing mixed content which you can do by looking at the page source or loading the page in Developer Tools (F12). You can also check the status of the certificate by clicking on the 'i' icon next to the padlock in the location field in both Chrome and Firefox.

Answer 2

Curious. That self-signed certificate creation date is Sunday, May 6th 2018.

1. Check your DNS. Run dig +noall +answer sub.domain-a.org sub.domain-b.org and check if both domains point to the same server. It seems you have no control of domain-b.org, so probably your client have changed their DNS configuration.
2. Check your nginx config, if there's any server block serving sub.domain-b.org and default_server, that could be the culprit; yet it seems you haven't changed any of your nginx configurations before, so I doubt it.
3. Check your certificate. Run openssl x509 -in /path/to/certificate/public_key.pem -noout -text with /path/to/certificate/public_key.pem points to your certificate in the snippet/ssl.conf. Check the issuer of the certificate.

Answer 3

I contacted the hosting provider of domain-b.org since I couldn't find any problems on my server side. Luckily they answered quickly and told me they recently migrated their control panel from an old system to Plesk. For some reason they couldn't tell me, they did not migrate any subdomains. So I was checking my DNS config in their old panel, which showed that everything was fine, while it wasn't.

The first command mforsetti gave in his answer also confirms this: the sub.domain-b.org was pointing to a server of the hosting provider. I never thought of doing a DNS lookup because I was convinced I was having the DNS records right in front of me in their old panel.

I'm trying to get access to their Plesk panel now and it will be fixed by simply adding the A record once again.