4 ms·

> The only real answer to this is to use Wildcard Certificates. You can get a TLS certificate for *.internal.example.com Does Let's Encrypt support Subject Alt

> The only real answer to this is to use Wildcard Certificates. You can get a TLS certificate for *.internal.example.com Does Let's Encrypt support Subject Alt Names on the wildcard certs? My experience suggests that wildcard certs work, but require a SAN entry for each "real" host because browsers don't trust the CN field anymore. e.g., my *.apps.blah cert doesn't work unless I include all of the things I use it on - homeassistant.apps.blah, nodered.apps.blah, etc. Do Let's Encrypt certificates have something special that negates this requirement? Or am I completely wrong about the SAN requirement?

vladvasiliu 5y ago
I use a few wildcard certs from Amazon, and they work well on Firefox, Safari and Chrome.
Intermernet 5y ago
Wildcard certs from LE work fine for internal domains. I've been using one for a while now. I had to set up some cron jobs to copy them around and restart some services, but it seems to be working well.
formerly_proven 5y ago
The whole point of a wildcard certificate is that you don't have to exhaustively list all covered hostnames.
gregmac 5y ago
This sounds like something is broken in your client (or maybe server config)? I use Let's Encrypt wildcard certs quite extensively, both in production use at $dayjob and on my home network, and have never encountered anything like this. The only "trick" to wildcard certs is one for .apps.blah won't be valid for apps.blah. The normal way to handle this is request one with SANs .apps.blah and apps.blah. Similarly, it won't work for sub1.sub2.apps.blah. I don't run setups like this myself but if you need it I'd recommend using a separate *.sub2.apps.blah for that, mainly due to the potential for DNS issues when LE is validating. Same thing with multiple top-level domains. The reason is when renewing if one of N validations fail, your certificate gets re-issued without the failed domain which then means broken SSL. If you have completely separate certificates and validation of one fails the old (working) version stays in place. With normal renewals happening at 30 days before expiry, this means you have 29 days for this to resolve on its own, manually fix, etc, and LE even emails you a few days before expiry if a certificate hasn't been renewed.
1vuio0pswjnm7 5y ago
"Or am I completely wrong about the SAN requirement?" Not w/r/t Chromium. https://web.archive.org/web/20170611165205if_/https://bugs.chromium.org/p/chromium/issues/detail?id=308330 https://web.archive.org/web/20170611165205if_/https://bugs.c... https://web.archive.org/web/20171204094735if_/https://bugs.chromium.org/p/chromium/issues/detail?id=700595 https://web.archive.org/web/20171204094735if_/https://bugs.c... In tests I conducted with Chrome, the CN field could be omitted in self-signed server certs without any problems.

vladvasiliu 5y ago

I use a few wildcard certs from Amazon, and they work well on Firefox, Safari and Chrome.

Intermernet 5y ago

Wildcard certs from LE work fine for internal domains. I've been using one for a while now. I had to set up some cron jobs to copy them around and restart some services, but it seems to be working well.

formerly_proven 5y ago

The whole point of a wildcard certificate is that you don't have to exhaustively list all covered hostnames.

gregmac 5y ago

This sounds like something is broken in your client (or maybe server config)? I use Let's Encrypt wildcard certs quite extensively, both in production use at $dayjob and on my home network, and have never encountered anything like this. The only "trick" to wildcard certs is one for .apps.blah won't be valid for apps.blah. The normal way to handle this is request one with SANs .apps.blah and apps.blah. Similarly, it won't work for sub1.sub2.apps.blah. I don't run setups like this myself but if you need it I'd recommend using a separate *.sub2.apps.blah for that, mainly due to the potential for DNS issues when LE is validating. Same thing with multiple top-level domains. The reason is when renewing if one of N validations fail, your certificate gets re-issued without the failed domain which then means broken SSL. If you have completely separate certificates and validation of one fails the old (working) version stays in place. With normal renewals happening at 30 days before expiry, this means you have 29 days for this to resolve on its own, manually fix, etc, and LE even emails you a few days before expiry if a certificate hasn't been renewed.

1vuio0pswjnm7 5y ago

"Or am I completely wrong about the SAN requirement?" Not w/r/t Chromium. https://web.archive.org/web/20170611165205if_/https://bugs.chromium.org/p/chromium/issues/detail?id=308330 https://web.archive.org/web/20170611165205if_/https://bugs.c... https://web.archive.org/web/20171204094735if_/https://bugs.chromium.org/p/chromium/issues/detail?id=700595 https://web.archive.org/web/20171204094735if_/https://bugs.c... In tests I conducted with Chrome, the CN field could be omitted in self-signed server certs without any problems.