Certificate Request with Certbot timing out

Hi,

I would not think so... And it's actually wierd since other post requests are processed normally.

Is the issue persists?

Could you please try to run dig +short TXT whoami.ds.akahelp.net and share us the output?

Thank you

Yes, the issue is still persisting.

Here's the output:

"ns" "2620:171:fe:f0::4"

I even tested this with different clients (dehydrated and acme.sh) and all of them error out at the same stage (the POST to the LE API with the finalize URL). Acme.shā€™s error indicates that it recieved an error 52 from CURL (meaning no data was returned back to my server)?

Pinging @lestaff since the error only occurs when itā€™s finalizing the order.

Maybe they could find something at server-side (or akamai side)

Thank you

Thanks @stevenzhu, Iā€™ll see what they have to say.

Could MTU on the tunnel be the culprit? Wireguard is 1420 by default.

This is pretty odd. From our side, we never receive the finalize request from your client, even though itā€™s there in the logs. I guess itā€™s possible Akamai could be specifically blocking your finalize requests - maybe they have some content in them that Akamaiā€™s WAF doesnā€™t like. Iā€™ll see what I can find out.

So I just tested IIS and Certify the Web and certificate issuance works. However, nothing on Linux worksā€¦ This is getting very confusing.

Checking your certificate signing request

again. And found:

CSR Decoder - Check CSR to verify its contents has no problem. But

https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp

has some problems.

Missing items: Common name, Country, City/locality, Organization, State/province

Your CSR does not contain the following items: Common name, Country, City/locality, Organization, State/province

Checking the code of my own client: There I specified all these entries, Letsencrypt ignores them. But perhaps the Country is important.

But there

https://ssl-trust.com/SSL-Zertifikate/csr-decoder

is something interesting:

Checking your CSR

Version: 2 (0x2)

Checking one of my last CSR (created with Windows .NET command):

Version: 0 (0x0)

Has someone a CSR created via Certbot to check?

These are not important; Boulder does not check these.

I believe Version 2 is correct (corresponding to x509v3). Version 0 is incorrect, and I believe Boulder will reject it.

Also it's worth noting that this can't be a problem where Boulder is rejecting the CSR, because according to our logs, Boulder never received the CSR.

@unixfy, what are the differences between your Certify the Web instance and your Linux instance? I assuming they are different servers on different IP addresses? Were you issuing for the same hostname?

Both are running on the same machine with the same IP configuration (but different IP addresses). For the Linux instance I was issuing for gamecp.x2c0.net, for Windows I was issuing for rd.x2c0.net.

Can you try issuing for gamecp.x2c0.net from your Windows instance?

I've got the certificate, no reject.

1 Like

Looks like I was wrong. I was thinking about CSRs with an empty version field.

1 Like

The request to get a certificate succeeds with Certify the Web on gamecp.x2c0.net.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.