The problem of getting a certificate from staging mode

Help
1

In production mode, I get the certificate as before.
But using staging mode I started getting an error in the very last request, when all checks are done and all that is left is to get the certificate from the server.

Problem connecting to server (post for ; curl returned with 3)

 + Requesting certificate...
2023-07-11 18:26:10 - le error: Problem connecting to server (post for ; curl returned with 3)
 + Checking certificate...
        + error: failed to run x509 -text (Exitcode: 1)

Details:
Could not read certificate from <stdin>

I use my finalized dehydrated script.

But on the latest version of dehydrated 0.7.1 the problem is also reproduced if you change the url to staging/ in the settings.
dehidrated 0.7.1
https://acme-staging-v02.api.letsencrypt.org/directory

What exactly is the reason for the servers not working or another protocol change?
How should I modify the last call of dehidratet to make it work or send me a link to the documentation where this change is shown or to a fix in your certbot.

2

There is not enough detail to understand the exact problem.

But, I see from your prior post (link here) you had a custom ACME client. After you updated dehydrated to 0.7.1 did you apply all your custom changes to it?

I also see you got a wildcard cert on the staging system for s301.ilya.cf. How did you get those certs? And, what domain are you having problems with?

image
image2058×1017 367 KB

4 Likes
3

1 A little later I will modify the script to log the full json response from the request, I think that will help.
2 Yes! Dehidrated does not support staging or dns-01 manual or dns-01 via mysql.
3 Yes this is the domain I'm testing with!
The server creates it for me, but won't let me get it.
The difference between staging and prod is only in the url configuration and nothing else!
With prod I get the certificate as before, while staging shows me this error at the last step.

4

OK, let us know when you have that.

You should check the request you make to get the cert. There is probably something wrong in your format which is causing that to fail. The Let's Encrypt server would not reject a valid request after all the previous order and challenge requests worked.

5 Likes
5

I see what this is about.

Response from finalize request to production

{
  "status": "valid",
  "expires": "2023-07-19T17:18:32Z",
  "identifiers": [
    {
      "type": "dns",
      "value": "*.s303.ilya.cf"
    },
    {
      "type": "dns",
      "value": "s303.ilya.cf"
    }
  ],
  "authorizations": [
    "https://acme-v02.api.letsencrypt.org/acme/authz-v3/244993203787",
    "https://acme-v02.api.letsencrypt.org/acme/authz-v3/244993203797"
  ],
  "finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/1203625277/194497172237",
  "certificate": "https://acme-v02.api.letsencrypt.org/acme/cert/04fc0667253e59c9b8fe5beed39d36120830"
}

The status is "valid" and the "certificate" field is present and the certificate is being retrieved by it.

Response from finalize request for staging

{
  "status": "processing",
  "expires": "2023-07-19T17:17:51Z",
  "identifiers": [
    {
      "type": "dns",
      "value": "*.s303.ilya.cf"
    },
    {
      "type": "dns",
      "value": "s303.ilya.cf"
    }
  ],
  "authorizations": [
    "https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/7276151314",
    "https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/7276151324"
  ],
  "finalize": "https://acme-staging-v02.api.letsencrypt.org/acme/finalize/110642994/9721108754"
}

The status is "processing" and there is no "certificate" field without which it is impossible to get a certificate.

This is an unexpected response for dehydrated and it is NOT ready for this!

Do I understand correctly, when receiving a response with the status "processing", I should set a delay of 1 second and execute the request again until the status "valid" or other status is received?
If possible, please provide a link to the ACME2 protocol documentation and indicate the paragraph that describes how to handle this request.

6

3 URL malformed. The syntax was not correct.
OK, so it's an outbound curl request failure?
To an FQDN that it can't display?

2 Likes
7

Is your problem that staging still has Asynchronous Order Finalization turned on? Since a client is supposed to poll the finalize while the status is still "processing". I would expect dehydrated to handle that, though, but maybe it's one of the broken clients that only was ever tested on Let's Encrypt.

RFC 8555, page 48,

"processing": The certificate is being issued. Send a POST-as-GET
request after the time given in the Retry-After header field of
the response, if any.

6 Likes
9

Thank you!
I take it that what's in staging now will show up in production in a while and it needs to be implemented by me as soon as possible?

2 Likes
10

The latest information on the plans is in the announcement I linked to, that they have chosen to "indefinitely postpone enabling asynchronous finalization in prod", and that it will be "enabled in Staging for an extended period, to allow client authors and website operators to test and verify that their clients work with it".

But yes, you should implement handling if finalize stays in "processing" for a while, in order to comply with the spec and to be able to use other CAs which already use that status.

5 Likes
11

I think dehydrated has support for asynchronous order finalization since version 0.7.0 back in 2020:

6 Likes
12

Yeah, I messed that up in the porting process.

3 Likes
13

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