Ghost certificate is being sent for clients without SNI

[Nottt]

I was doing a ssllabs test and I found this strange certificate:

I don't know why it's being sent at all. I'm using jwilder/nginx-proxy:alpine with this settings:

VIRTUAL_HOST: domain1 domain2 domain3
VIRTUAL_PORT: 80
LETSENCRYPT_HOST: domain1 domain2 domain3
LETSENCRYPT_EMAIL: some@email.com

[buchdag]

That's the default, self signed certificate generated by the companion if you don't provide you own default certificate. And yes client without SNI will get either this certificate or the one you provided, that's expected.

The default behavior for the proxy when port 80 and 443 are exposed is as follows:

• If a container has a usable cert, port 80 will redirect to 443 for that container so that HTTPS is always preferred when available.
• If the container does not have a usable cert, a 503 will be returned.

Note that in the latter case, a browser may get an connection error as no certificate is available to establish a connection. A self-signed or generic cert named default.crt and default.key will allow a client browser to make a SSL connection (likely w/ a warning) and subsequently receive a 500.

https://github.com/jwilder/nginx-proxy#how-ssl-support-works

[Nottt]

Can I delete default.crt and default.pem safely to disable this behavior? I don't care about non-SNI clients.

[buchdag]

No, they'll get recreated when the container restarts.

If you don't have default certs, non SNI clients (or client trying to access the server by IP) will get a wrong certificate anyway, the certificate of the first proxyed service in the nginx config file if I recall correctly.

What behaviour would you like to see ? Again the default cert is only served to non SNI client, or client reaching the server through IP or non configured domain, if you don't care about them I'm not sure I understand the issue.

[Nottt]

I'd like to never display a warning with my URL at all. I don't know what happens when a non SNI client tries to access a SNI server only. I suppose there will be some kind of warning telling them to upgrade or something. That's better than a giant, red screen telling my domain is not secure.

If not, the ideal solution would be to display a blank page in https (maybe with a different subdomain... something like error.domain.com) telling them to upgrade their client if they want to visit the website.

HTTP could work, but all my domains have HSTS so that's not a option. I don't understand why you can't at least have the default certs being a subdomain with a valid cert at all?

If someone access my website with a non-SNI client, I don't want to scare them away. Do you think the average user will understand that it's their fault and not my website?

Also if that website can see I'm serving invalid cert, search engines can too. Will they find that suspicious? I don't know. Why would a domain be serving a valid & invalid certificate?

[buchdag]

I don't know what happens when a non SNI client tries to access a SNI server only.

It will most probably reach another site on the same server than the one it's trying to connect to and will get a certificate mismatch warning.

I suppose there will be some kind of warning telling them to upgrade or something.

Nope. The obsolete client isn't aware of the reason why it is getting a mismatched certificate.

If not, the ideal solution would be to display a blank page in https (maybe with a different subdomain... something like error.domain.com) telling them to upgrade their client if they want to visit the website.

I think you might be able to do this with nginx-proxy default domain option + a custom default certificate. Not sure though. Check the docs.

I don't understand why you can't at least have the default certs being a subdomain with a valid cert at all?

You are free to symlink the default cert and key to an existing cert and private key. As told previously the self signed default certificate only gets created when you don't provide your own default cert and key.

If someone access my website with a non-SNI client, I don't want to scare them away. Do you think the average user will understand that it's their fault and not my website?

Also if that website can see I'm serving invalid cert, search engines can too. Will they find that suspicious? I don't know. Why would a domain be serving a valid & invalid certificate?

This is how name based shared hosting has been working for years if not decades all over the world. Does not seem to be an issue at all in the long run.

[Nottt]

I understand. I'll try stuff and report back here if you wish. Thanks

[aliceinwire]

@Nottt news on this ?

[mosesrenegade]

I know this is a 'wontfix' issue, but it's probably not the ideal way to do this. It would provide anyone scanning the internet at large with the capability to fingerprint the architecture of the system. For example, now that I'm running this setup, I can tell that anyone running a certificate with the name: letsencrypt-nginx-proxy-companion as the hostname is probably running the two containers that are listed here.

Maybe there is a way to obfuscate the naming and the mechanism used to deliver this certificate to obfuscate this further so it's not so obvious?

[buchdag]

@mosesrenegade Yep, I'm aware of that but I did not come up with a better solution yet (one that would both enable the container to recognize if the default certificate / key are its own self generate ones and defeat fingerprinting).

My thought was that a certificate requires a subject name and that subject name is going to be exposed to the outside world no matter what. Going from there I did not see a way to make the subject name not opening up the door to fingerprinting. Even a random subject name would give it away because the way we would implement that would probably be unique enough to be fingerprinted.

I'm open to suggestions and/or PRs.