Not a problem, just wondering why

I’m checking out a website via Qualsys SSLlabs checker and get this cert info, and wondering what it means. Is the site hosted externally with a large ISP perhaps? Or can it be that the server is returning an extra certificate that it shouldn’t be? AFAIK it is hosted internally via Drupal on nginx (sorry for colors that’s this blog engine):

Certificate #1: RSA 2048 bits (SHA256withRSA)

Fingerprint SHA256: 3c664bc10443f04a0d846c92fc0547ee92ff58473a9b7c4501c7e6add610013d
Pin SHA256: Q8h8cEcUrZgQzNTvKB1kgWQ6jigjjQ2Ox0Y7AQ86BZM=
Common names
Alternative names
Serial Number 04943f9e4144e612224d90895e2b3906ff5e
Valid from Thu, 21 Mar 2019 17:07:15 UTC
Valid until Wed, 19 Jun 2019 17:07:15 UTC (expires in 2 months and 24 days)
Key RSA 2048 bits (e 65537)
Weak key (Debian) No
Issuer Let's Encrypt Authority X3 
Signature algorithm SHA256withRSA
Extended Validation No
Certificate Transparency Yes (certificate)
OCSP Must Staple No
Revocation information OCSP 
Revocation status Good (not revoked)
Trusted Yes   Mozilla  Apple  Android  Java  Windows


Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI

Server Key and Certificate #1
Subject * 
Fingerprint SHA256: 7761023ff4ba4b45c29af354255875ba57d6929179ccd0b7a75861c9685f8f36
Pin SHA256: m1kkceOTfyg+kIV8n2wjmjOE9Owo/gzZ2ySAm0Lvkb8=
Common names *
Alternative names * * * *    **MISMATCH**
Serial Number 06fcb0bbe23732d7bedf562d4367adfd
Valid from Wed, 06 Mar 2019 00:00:00 UTC
Valid until Mon, 30 Mar 2020 12:00:00 UTC (expires in 1 year)
Key RSA 2048 bits (e 65537)
Weak key (Debian) No
Issuer DigiCert SHA2 Secure Server CA 
Signature algorithm SHA256withRSA
Extended Validation No
Certificate Transparency Yes (certificate)
OCSP Must Staple No
Revocation information CRL, OCSP 
Revocation status Good (not revoked)
Trusted No    NOT TRUSTED   Mozilla  Apple  Android  Java  Windows

Thanks for any insight you can give.

The keyword (or sentence) here is the “No SNI” part.

For more information, see:

So the second cert is presented to the browser if it doesn’t understand SNI? Why all of the disparate domains in the first cert then?

The first certificate seems to be a large one that was obtained by the hosting provider for many customers, while the second one seems to be the hosting provider’s own cert, which is served if it doesn’t know which particular site the visitor is trying to connect to (which is the no-SNI condition).

So that means this is a hosted site on a large ISP and not a single site on a local server? Huh…

Hi @mushu

you can see the same effect on smaller sites.

A wildcard as standard certificate, so all (customer specific) subdomains use that wildcard certificate.

Additional, some explicit certificates (www + non-www per domain) with SNI.

Result: Checking one of these explicit domains the wildcard certificate is shown - "without SNI".

Sure, but does that mean all of those sites listed in that wildcard cert are hosted on that ISP server?

The wildcard cert isn’t interesting, that’s just a cert of the hosting provider.

The first certificate you presented is “sort of” more interesting. A small sample of those hostnames all resolve to the IP address, most of them through a CNAME pointing to

So yes, it seems many, if not all of those hostnames are hosted behind a single IP address on a large hosting provider called Pantheon.

It’s possible that they have a CDN-like architecture and use something like proxy_pass to forward individual connections to individual servers, but the simplest interpretation would be that it’s hosted in a large shared environment.

Okay that makes sense. I found it interesting that .gov sites were also hosted there, although I guess that doesn’t make it any less secure. It’s just that there are unique requirements for data and privacy that ISPs generally can’t accommodate since they have so many clients.

Yes, that's possible. I have such a subdomain service, so every customer has a subdomain that works with the wildcard certificate. Some customers use own domains and have domain-specific certificates. They can use both - the subdomain and the own address.

But I thought SNI was controlled by the server, not the certificate. Isn’t the cert just used as a kind of “key” to the “building front door”? After the door is opened the long hallway of SNI has many other doors but all have a different “nameplate” yet are in the same “building”. If you get that. So how does a cert control whether the client understands SNI, isn’t that part of the code in the browser? That’s why an old browser like IE 6 doesn’t know SNI but all new browsers do…or am I totally off-base here?

SNI is presented before the server decides which certificate to show, unlike the HTTP Host: header, which is presented after. The server can choose a certificate on the basis of the SNI field (and usually does, in HTTPS virtual hosting, in order to ensure a certificate match and not generate a browser error!).

The server could then also choose a specific virtual host on the basis of the HTTP Host: header. Usually this header agrees with the SNI value; when they don’t agree, we have “domain fronting” if the server decides to prefer the Host: header’s indication over the SNI indication.

1 Like

A server can have something like a standard vHost. If there is no special hostname defined, this standard vHost is used. There is the wildcard certificate (worked without SNI).

With SNI, it's possible to define different vHosts (bindings) with individual hostnames and certificates.

Result: -> * - certificate. -> - certificate.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.