Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
All letsencrypt certificates stopped working today even though they aren't expired.
My domain is: all domains that use lets encrypt. One as an example is www.gigshowcase.com
I ran this command:
It produced this output:
My web server is (include version): Windows server 2022 Standard 21H2
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
You're going to have to give more details. Are you the administrator of these sites? Or just unable to connect to other web sites (like this forum?) that use Let's Encrypt. If you're the administrator and set them up to use Let's Encrypt, how did you do so?
Still not a lot of information to go on. It looks like that name is currently serving a Digicert certificate for a different domain name. So I would suggest first double-checking that your IPs point to where you think they should, and that your server configuration is serving the right certificates for your names.
All the letsencrypt certificates when you browse to the sites say the certificate is invalid and it is showing another certificate *.hoaguru.com which is not a letsencrypt certificate. But the bindings are set to the letsencrypt certificates, not the *.hoaguru.com cert. I didn't touch any of this recently.
Both gigshowcase.com and hoaguru.com point to the same IP address, and clicking past the security warning shows the gigshowcase site with the hoaguru cert.
There was likely a system update or configuration change that you didn't realize. I would check your server config.
Certificates are not active code so cannot change behavior by themselves. They are static data.
As my fellow volunteers have said something that uses those certs has changed. I know it can be frustrating when you haven't intentionally changed something but something on your system must have changed.
You would be better off asking on a Windows IIS forum on how to check your bindings and cert assignments. There are some Windows expert volunteers here but an IIS forum is still probably best.
I don't know much about IIS myself but googling says use netsh to verify the bindings. Like netsh show http sslcert
I checked every binding and made sure to select the specific IP address instead of all unassigned like some forums said. All the bindings with ssl have a host name and Require Server Name Indication Checked.
I don't know what else to do! Is there any help you can give me on this? I hadn't changed any SSL or binding settings recently and they just stopped working today.
It just serves the *.hoaguru ssl certificate to all sites even if they are pointing to a different ssl cert in the bindings.
The sites that do use the *.hoaguru.com ssl cert are very important. I cannot remove them.
As unusual as it may seem, to me there can only be a few places where things could go this way:
IIS
[has anything changed recently]
certificate store
[has anyone added/removed any certs recently]
I'd review recently applied Windows Updates for anything cert related.
I'd also try issuing a cert from another CA to see if the LE is actually part of this problem [or not].
Another possibility although this would be extremely unlikely is something wrong or changed in your hosting service. Perhaps their network routing has affected the SNI hostname such that your system handles everything as if SNI was not set.
I tried several of your domains using SNI and not providing the SNI hostname and your system always uses the same cert.
I'll repeat though ... I think your best avenue for support is an IIS specialty team or perhaps your hosting service. Below output is condensed
# Normal SNI connect
echo|openssl s_client -connect www.gigshowcase.com:443
Certificate chain
0 s:CN = *.hoaguru.com
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1
v:NotBefore: Jan 17 00:00:00 2024 GMT; NotAfter: Jan 19 23:59:59 2025 GMT
# No SNI hostname (same cert)
echo|openssl s_client -connect www.gigshowcase.com:443 --noservername
Certificate chain
0 s:CN = *.hoaguru.com
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1
v:NotBefore: Jan 17 00:00:00 2024 GMT; NotAfter: Jan 19 23:59:59 2025 GMT
Everything started working now. Not sure what caused it. Also, not sure what fixed it. I think there was some caching that happened so it was all delayed, making it impossible to know which thing I tried that fixed it.
This problem is almost always caused by an IP specific binding. Unless you absolutely know you need an IP specific binding (e.g. the IP is set to the machine IP instead of the default All Unassigned) then all https bindings should be IP: All Unassigned, Hostname: <your domain>, Server Name Indication: enabled
To really analyse all the bindings on a machine try netsh http show sslcert > bindings.txt then look at the bindings.txt file for any IP specific bindings (IP:port, they should otherwise be Hostname:port): Using Certificates in Windows | Certify The Web Docs
Note that it was common in the past to use IP specific bindings because this was required before Server 2012 and SNI came along, sometime the practise is carried forward without realizing what it does. Before SNI each certificate bound to port 443 needed it's own associated IP address, that was also back when SSL was a bit less common and tended to be used for ecommerce sites etc more than standard sites.
[Also watch out for setting what IIS calls a "default SSL site", this is intended for older pre-SNI clients and you do not need it.]
