Certificate issued in error?

I renewed a certificate but I believe it should not have been possible because the HTTP validation should have failed based on my server logs and firewall configurations at the time of renewal. I confirmed the behavior from another system, and indeed the challenge should have failed when the Let's Encrypt servers tried to validate the challenge. How can we verify this apparently erroneous issuance?

1 Like

Tell us more. What domain, why would it fail?


Also, what ACME software are you using, and which challenge type? Can you provide logs from your ACME client?


Hi jsha,

The client is home-built, but uses the HTTP method. I imagine the logs won't be terribly useful to anyone else because of that. They are below, nonetheless (read bottom to top).

[ 5/13/22-17:04:33]  Setting Folders for Domain [flint-dev.<redacted>.net]
[ 5/13/22-16:30:56]  Server Restarted
[ 5/13/22-16:30:56]  Dates: flint-dev.<redacted>.net From:13 MAY 2022 To:11 AUG 2022
[ 5/13/22-16:30:55]  Setting Folders for Domain [flint-dev.<redacted>.net]
[ 5/13/22-16:30:55]  Certificate received For flint-dev.<redacted>.net
[ 5/13/22-16:30:55]  Requesting Certificate For flint-dev.<redacted>.net
[ 5/13/22-16:30:55]  Finalized. Will now fetch certificate
[ 5/13/22-16:30:54]  Finalize Request flint-dev.<redacted>.net
[ 5/13/22-16:30:53]  Hostname resolved to: <IP_redacted>
[ 5/13/22-16:30:53]  Challenge was valid. Will now finalize
[ 5/13/22-16:30:53]  Status: "valid"
[ 5/13/22-16:30:53]  Get Authorize flint-dev.<redacted>.net
[ 5/13/22-16:30:52]  Checking Status
[ 5/13/22-16:30:52]  Notify Server Challenge is Ready
[ 5/13/22-16:30:52]  LE Server will now fetch http://flint-dev.<redacted>.net:80/.well-known/acme-challenge/gdo3Y65SPgZgs9rP9XrSwFIima6X-1_cil1BjxE3fF0
[ 5/13/22-16:30:52]  Challenge Token Saved C:\WebApp\ws\.well-known\acme-challenge\gdo3Y65SPgZgs9rP9XrSwFIima6X-1_cil1BjxE3fF0
[ 5/13/22-16:30:52]  Get Authorize flint-dev.<redacted>.net
[ 5/13/22-16:30:51]  Authorize Request flint-dev.<redacted>.net
[ 5/13/22-16:30:51]  Registering Account <CA_redacted> at  https://acme-v02.api.letsencrypt.org/acme/new-acct
[ 5/13/22-16:30:49]  Time to update the certificate flint-dev.<redacted>.net
[ 5/13/22-16:30:49]  Dates: flint-dev.<redacted>.net From:24 FEB 2022 To:25 MAY 2022
[ 5/13/22-16:30:49]  Setting Folders for Domain [flint-dev.<redacted>.net]
[ 5/13/22-16:30:49]  Created C:\certificates\flint-dev.<redacted>.net.csr.der
[ 5/13/22-16:30:48]  Setting Folders for Domain [flint-dev.<redacted>.net]

I discovered the issue when I went to close the port back up (because I thought it was open, since the certificate was successfully renewed), but the port was already closed/filtering. I tested the challenge request again from another network to prove that the port was closed/filtering, and confirmed this to be the case. An hour later, I did open the port, and confirmed from the external network that I could request the challenge and get the correct response, just as LE servers should do, which worked. I then closed the port back up and confirmed the request should fail, and it did fail. At no point did I have any requests from LE servers successfully hit my web server.

(edit) all times are UTC-06:00

1 Like

You issued two certificates for your domain:

  • One on the 3rd of May
  • A second one on the 13th of May

Assuming you used the same ACME account both times, the second certificate issuance would not have required a fresh authorization for your domain name.

Let's Encrypt will reuse authorizations for up to 30 days (last I checked anyway). When this happens, upon creating an order, you will see that the authorization is the same as the one from your original order, with a status of valid.

If you want, you can prevent this happening by deactivating all authorizations in the order after you have finalized the order and downloaded the certificate.

Hope that helps.


Hi _az,

This helps a lot, thank you! Yes, I would have used the same account both times, and had planned to manually transfer the cert files acquired May 3rd, but my ACME client beat me to it. I have never observed this behavior before, and I didn't know this was part of the spec, thus my confusion.

Thank you all for clearing this up!


Technically, it's not. It's an implementation choice made by Let's Encrypt (and as such, it's not guaranteed to work the same way forever). :grinning: