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

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 {

# 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_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 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;
  • Please add contents of include snippets/ssl.conf; include snippets/ssl-params.conf;. That's probably where the magic happens. – Esa Jokinen Jul 3 '18 at 13:25
  • I've added the ssl-params.conf. The ssl.conf doesn't contain anything except for a path to the certificate and the certificate-key. – StefK Jul 3 '18 at 14:40
  • If ssl.conf contains the paths, I think that’s where the answer will lie. If you look closer at the image a self-signed cert is being returned for this domain. Does a machine called PROD-WEB-xxxx look familiar at all? – David Hutchison Jul 3 '18 at 15:00
  • Nope. Not at all. The certificates are being generated by letsencrypt. When looking at the certificate returned by sub.domain-a.org, it's clearly issued by letsencrypt. It's only when navigating to sub.domain-b.org that it somehow returns a self-signed certificate. Would it somehow be possible that there is a self-signed certificate on domain-b.org that is forcing itself in being used? When navigating to domain-b.org HTTPS is not forced though. When navigating explicitly to domain-b.org I get yet another invalid certificate issued by the hosting-provider of that website. – StefK Jul 3 '18 at 15:07

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.

  • Firefox says the connection is not secured, since it can't find the certificate for some reason. I can't imagine this being a mixed content issue since it is working fine for sub.domain-a.org which is the exact same server serving pages as sub.domain-b.org. – StefK Jul 3 '18 at 8:58
  • You presumably have separate configurations for sub.domain-a.org and sub.domain-b.org so check that. – Simon Greenwood Jul 3 '18 at 9:56
  • Separate configurations where? Those two domains point to the exact same server, which has a multi domain certificate in which both domains are included. – StefK Jul 3 '18 at 11:14
  • Your web server needs to know how to route the hostnames and you would normally have a virtual server configuration for each. It is almost certainly going to be something to do with that. – Simon Greenwood Jul 3 '18 at 11:19
  • I've added my nginx config. I don't think I ever changed it. I just added an A-record for sub.domain-b.org, renewed the certificate to be multi-domain and all was good for months up until now. Might be I'm missing something in the config either way. I'm far from a specialist. But the fact that it was working up until now is baffling me. – StefK Jul 3 '18 at 11:40

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.