I was hoping you might be able to assist me in isolating why automatic rebind of renewed certificate is not working for android.cleanuniforms.com
1 Like
What do you mean?
I see the 2026/2/23 R13 cert being served:
openssl s_client -connect android.cleanuniforms.com:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R13
verify return:1
depth=0 CN = android.cleanuniforms.com
verify return:1
---
Certificate chain
0 s:CN = android.cleanuniforms.com
i:C = US, O = Let's Encrypt, CN = R13
a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
v:NotBefore: Feb 23 14:03:57 2026 GMT; NotAfter: May 24 14:03:56 2026 GMT
1 s:C = US, O = Let's Encrypt, CN = R13
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
3 Likes
yes, but it does not auto rebind like all of the rest of our Let's Encrypt certs. I have to go into IIS for that particular site every few months and bind the new cert to the site. I'm curious to know what's different here and why that step is only necessary for this one domain out of a bunch of others we maintain that do not require that step. Thanks for getting back to me and helping me isolate the issue.
-BK
Which ACME client are you using?
Describe the process used to obtain and install the cert.
Is this cert being handled differently than the others?
5 Likes
The ACME client you are using has to know which IIS sites to update the binding for. It depends which one you are using as to how it does that. I don't recognise the Friendly Name naming scheme but maybe it's win-acme? Maybe not. I make Certify Certificate Manager and it puts [certify] in the name.
If your https binding does not have a hostname set, that would be the problem.
An alternative is to use CCS (centralized certificate store) where you just output the cert to a directory (with a file naming convention) and IIS picks it up based on the filename, without having to change the https binding.
4 Likes
The binding issue here is a configuration mismatch between how the ACME client knows the cert and how IIS tracks the binding.
When you set up a binding manually by selecting a cert by thumbprint, IIS locks to that specific cert object. When the ACME client renews, it creates a new object with a new thumbprint and the binding doesn't follow automatically. That's why the other certs work: they were probably configured to use Centralized Certificate Store or their ACME client has a binding hook set up.
Two ways to fix it. First option: use the Centralized Certificate Store binding method in IIS. Instead of binding to a cert by thumbprint, IIS looks up the cert by filename in a folder, so when the ACME client writes a new file, the binding auto-updates. The catch is the hostname has to match the filename exactly. Second option: make sure your ACME client has a renewal hook configured that runs a PowerShell script to update that specific binding after renewal.
Certify the Web handles this well on Windows if you want to run an ACME client on it. Or the CertKit agent will pull certificates and update the IIS bindings without needing to handle ACME.
We are using win-acme. I have attached the win-acme log file from the last time the auto-renewal took place and succeeded but did not auto rebind. Is there any useful in the log file that might pinpoint what's occurring?
log-20260223.txt (23.2 KB)
It looks like the renewal is executing just fine and there don’t seem to be any errors in that log.
It’s not really an win-acme error, its however your binding is working. You might want to just change it to have a post-renewal hook or script that points your software at the new certificate.
I think it's this:
2026-02-23 10:02:28.696 -05:00 [ERR] The previous certificate was detected in IIS. Configure the IIS installation step to auto-update bindings.
You probably just need to revisit that certificate configuration in win-acme.
1 Like