1

when running ssllabs.com's test on my website, the output contains "Certificate #2" for (one of the) other domains hosted on the NGINX web server. It is red and not Trusted but I prefer to simply not have this option, where a program can see which other domains are hosted on this server.enter image description here

Julius Baer
  • 23
  • 4
  • Is that the "No SNI" certificate? – Richard Smith Apr 08 '21 at 08:05
  • In order to hide those, you should have a new certificate issued which does not include them, and set it up. – Danila Vershinin Apr 08 '21 at 12:08
  • @RichardSmith: yes it is. DanilaVershinin: I use certbot to issue the certificates one by one (one domain by one domain). – Julius Baer Apr 09 '21 at 07:05
  • @DanilaVershinin Yea, but how is this done with a Let'sEncrypt certificate using certbot? If I go to ssls.com and order a cert I don't get these alternative names. If I run `certbot --nginx` then I get them so I suspect that certbot is reading the nginx config and add the other domains them as alternative names. – Altimus Prime Oct 19 '21 at 12:23

2 Answers2

1

If your server is contacted with an older https protocol (without SNI), or even by using its IP address instead of a domain name, Nginx will choose the default server block and use whichever certificate is associated with it.

The test results you are seeing are simply identifying which server block is the default.

You can choose which certificate Nginx should use in these cases, by marking one of your server blocks (which listen for https connections) with the default_server attribute.

For example:

server {
    listen 443 ssl default_server;
    ssl_certificate     ...;
    ssl_certificate_key ...;
    ...
}

You can even choose to reject these connections with a return 444; statement, but you will still need a valid certificate to negotiate the connection in the first place.

See the documentation on default servers and HTTPS servers.

Richard Smith
  • 11,859
  • 2
  • 18
  • 26
  • Thank you. I actually have `listen 443 ssl; # default_server;` in all sites-enabled, so with that commented out. Same for `listen[::]:443; # ssl default_server;` However, it seems to then choose the first one domain in sites-enabled/ alphabetically as default. So the commenting out doesn't suppress the others. I can indeed `return 444` or choose one of my domains as a default. But does that (or what does?) definitely hide the other domains? – Julius Baer Apr 10 '21 at 12:10
0

When a browser dialogs with a server in a https://<server name> transaction, one of the first steps is that the server shows its certificate in order to allow browsers to check that server pages come from where they declare to come from. A browser decides that the server is valid if <server name> is in the certificate that the server shows and the certificate is signed by an authority in which the browser trusts.

The field that browsers use to check the server name is not CN (Common Name) as it would be expected. For historical reasons, browsers actually check that the name is in the "Subject Alternative Names" field. That's to say, if you use a certificate without the name of a server in the list "Subject Alternative Names", browsers will receive an error if they try to reach that name.

So, if you want to use certificates for a site that include no information for other sites, you must make use of a different certificate for each one of the sites served by the same host.

Julius Baer
  • 23
  • 4
J.M. Robles
  • 865
  • 6
  • 9
  • Different certificates can be used with the Server Name Indication extension to the SSL protocol, which is supported by a reasonable percentage of clients by now. The downside is that the server name the client is trying to reach is then discoverable for network sniffers, while a session using a certificate with multiple names only tells the set of possible host names in cleartext. – Simon Richter Apr 09 '21 at 06:58
  • @JMRobles I use certbot to obtain SSL certificates one by one. The behavior I describe does not occur with all domain names. I think it mainly occurs with the default domain. That is, the domain www..com itself doesn't give this red (MISMATCH, No NOT TRUSTED) result. – Julius Baer Apr 09 '21 at 07:10
  • @SimonRichter: I don't want to show any other domain names. I don't understand your comment frankly. I use NGINX, is there an explicit configuration statement that says, "don't list alternative names" or is this something in the SSL certificate issued by Let's Encrypt? And if the latter, then can certbot avoid adding these alternatives to the certificates? – Julius Baer Apr 09 '21 at 07:16
  • @JuliusBaer, Alternative Names is the "subjectAltNames" field in the certificate, which is part of the signed data in the certificate, so it is not possible to omit or alter this without invalidating the certificate. Looking at the certificates I got from LetsEncrypt, they seem to include a subjectAltName field, this is consistent with the common interpretation that using the CN subfield in the subject field is deprecated and only kept for older clients. – Simon Richter Apr 09 '21 at 07:31
  • @SimonRichter do you think that when asking LetsEncrypt for a certificate (using -d domainB), it contacts the web server by the IP address and by that receives the alternative name domainA (because domainA is listed as the default)? – Julius Baer Apr 10 '21 at 12:02
  • (I can easily replace these certificates) – Julius Baer Apr 10 '21 at 12:12
  • @JuliusBaer, no, certificates are issued for the requested name or not at all. The subjectAltName field is supposed to be in there, as that is the primary method of giving the webserver name today, the CN field is just a fallback now. – Simon Richter Apr 10 '21 at 18:04
  • @SimonRichter, but I don't send the alternative names when requesting LE certificates with certbot. So why can ssllabs see those alternative names in the certificates? – Julius Baer Apr 11 '21 at 09:42
  • @JuliusBaer, the primary host name is also in the list of "alternative" names. If you look at the certificate with `openssl x509 -in cert.pem -noout -text`, you should be able to see it – Simon Richter Apr 11 '21 at 10:03
  • Yes, the primary hostname is in the output, under `X509v3 Subject Alternative Name` so, why does SSLLabs see the other domain name? It must be using the IP address then and getting a default name as @RichardSmith partly described above. – Julius Baer Apr 11 '21 at 11:07
  • 1
    I'm having the same issue. Wondering if there some sort of caching going on with ssllabs. Did you ever figure this one out? – DanRan Jul 19 '21 at 20:37