Error on new cert: Certificate not found

[wolfewa]

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: www.awolfe-grc.info

I ran this command: sudo certbot --nginx

It produced this output:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.awolfe-grc.info
Waiting for verification…
Cleaning up challenges
An unexpected error occurred:
The request message was malformed :: Certificate not found

My web server is (include version):Nginx 1.18.0

The operating system my web server runs on is (include version):Ubuntu 20

My hosting provider, if applicable, is: none

I can login to a root shell on my machine (yes or no, or I don’t know):Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):1.6.0

All seems to work until I get to the end when I get the Cert not found error not sure where to look to troubleshoot.

This is just a very basic site I am just doing some testing on run on a simple server with nothing else running. It is behind a NAT/ firewall so only 80 and 443 are passed to the server from the public IP

[Osiris]

Could you please paste the output of letsencrypt.log between three backticks? (I.e., above and below the output of the log put ``` on a single line.)

Alternatively you could also run certbot again with the same options but with -v (for verbose) added. This provides more info, but I think a little less than the log file, which is ridiculously verbose)

[Rip]

@wolfewa @Osiris

FYI:

@wolfewa

only 80 and 443 are passed to the server from the public IP

PORT    STATE  SERVICE
80/tcp  open   http
443/tcp closed https

Rip

[wolfewa]

There is a lot of stuff but here are the key lines I think

‘’’ 2020-07-13 17:20:53,622:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 “POST /acme/cert/{certnumber removed} HTTP/1.1” 404 106
2020-07-13 17:20:53,625:DEBUG:acme.client:Received response:
HTTP 404
Server: nginx
Date: Mon, 13 Jul 2020 17:20:53 GMT
Content-Type: application/problem+json
Content-Length: 106
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel=“index”
Replay-Nonce: {number removed}

{
“type”: “urn:ietf:params:acme:error:malformed”,
“detail”: “Certificate not found”,
“status”: 404
}
2020-07-13 17:20:53,626:DEBUG:certbot._internal.log:Exiting abnormally:2020-07-13 17:20:53,637:ERROR:certbot._internal.log:An unexpected error occurred:
2020-07-13 17:20:53,637:ERROR:certbot._internal.log:The request message was malformed :: Certificate not found

Thanks for any help

[wolfewa]

I think it is showing closed because I have not been able to set up the cert so the web server is not replying to 443 yet

[Osiris]

Strange… For some reason you’re getting a certificate issued (see https://crt.sh/?id=3082916701 for your certificate), but the Let’s Encrypt server can’t find it itself?

@jsha Any idea how we could debug this?

[wolfewa]

Osiris,

First thanks for the help!!! A few things I am using the beta Snap version of the Certbot not sure if that is causing issues. Second when I go to the link in your message crt.sh I get a bad gateway.

[wolfewa]

Ok never mind on the second one I can get to the cert report now

[schoen]

@lestaff this does seem like a fairly concerning internal CA issue if the ACME endpoint sometimes can’t successfully look up its own issued certificates.

[jsha]

The certificate issued by @wolfewa exists and retrieves just fine:

$ curl -s https://acme-v02.api.letsencrypt.org/acme/cert/033930efd3ca70260faaa2c03efa68a38b1d | openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:39:30:ef:d3:ca:70:26:0f:aa:a2:c0:3e:fa:68:a3:8b:1d
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Jul 13 16:20:46 2020 GMT
            Not After : Oct 11 16:20:46 2020 GMT
        Subject: CN = www.awolfe-grc.info

(Note that certificate serial numbers are not secret and don’t need to be redacted; they are published automatically to CT).

I’m not sure why Certbot failed to retrieve in this case. Perhaps the POST-as-GET request was signed with the wrong account key?

[jsha]

I dug deeper in the logs and found the answer: Certbot’s request to download the certificate got a timeout trying to request the certificate from the database. Normally that should be a 500 (Internal Server Error). But it looks like Boulder has a bug where it is reporting this particular timeout as a 404 instead. I’ll get that fixed.

Edited to add: https://github.com/letsencrypt/boulder/issues/4950

[wolfewa]

Hi @jsha

Thank you for your help. I am not clear on next steps can I just rerun sudo certbot --nginx and it should work or do I need to use a different method to retrieve the private key and cert?

Right now I have no web cert to use for TLS traffic on the server. If there is a fact-filled document I should read I will take a pointer as well.

Thanks

[jsha]

In this case you’ve only issued one certificate so you’re not likely to run into rate limits. I think you should just re-run sudo certbot --nginx. Now, if that errors again we might want to look at things like manually setting up the certificate retrieved from the URL I shared above, so you don’t run into rate limits. But I think you should succeed if you just try again.

[wolfewa]

And there was joy in Mudville thank you @jsha and @Osiris for your amazingly fast support.
It looks to be working as expected, boring site but as expected.

[jsha]

Somewhere men are laughing; somewhere children do the same;
There’s no call for sorrow here; mighty Casey’s won the game!