Authorization staus invalid after the second response

Help
1

Hi,

I’m writing on behalf of Tutanota. We use Let’s Encrypt to automatically order certificates for our customers. Recently we ran into a problem when we are unable to order a certificate for one of our customers. In the logs we see that we respond to the HTTP challenge twice, after which authorization status becomes invalid. We are unsure why this is the case. We successfully order other domains (including mta-sts.valence.nl) but this one consistently fails. We would appreciate some help or clarifications on how we can get more information (we only see authorization status, no error is returned)

My domain is: email.valence.nl

My web server is (include version): Custom

The operating system my web server runs on is (include version): Debian Buster

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): acme4j 2.6

1 Like
2

Hi @charlag

what does that mean? Do you post two times to the challenge url? Then it's a bug of your client.

Or is the validation file /.well-known/acme-challenge/random-filename two times fetched via GET?

If yes, that should be 4 times.

So some validations may fail.

What's the exact error message from Letsencrypt?

1 Like
3

Thank you for reply.
The challenge is requested multiple times, like usual. After the first challenge request we start polling for the order status. After the second GET request from Let’s Encrypt for a challenge we see that order status becomes INVALID. Field error on the order in null. Status of the only element in authorizations becomes invalid.

So, you could say that we are not getting any errors. If there is another way to get the error?

We suspect that it might be related to the rate limiting but we expect to not be able to place the orders then.

4

The error should be detailed inside the authorization URL.

Could you share an example order URL suffering from the issue?

So far, this sounds like a perfectly ordinary authorization failure. The multiple requests are probably just due to parallel multi-vantage validation.

5

I’m not sure what “inside the authorization URL” means, sorry.
Here is an example, it failed after three requests this time.

 I XX:44:17.828 sys AcmeFacade.java:100 pool-1-thread-1 ordering domain email.valence.nl -  -  - 
 I XX:44:19.471 sys AcmeFacade.java:188 qtp1275013351-155603 Handling request http://email.valence.nl/.well-known/acme-challenge/bk7-6Ce4H0yJoDHtbaYLxIkx_UzJck2Mwfh5rolX9Jc -  -  - 
 I XX:44:19.494 sys AcmeFacade.java:121 pool-1-thread-1 Pending order: PendingOrder{domain='email.valence.nl', state=PENDING, order status=PENDING, order problem=null, order authorizations status=PENDING} -  -  - 
 I XX:44:20.044 sys AcmeFacade.java:188 qtp1275013351-161312 Handling request http://email.valence.nl/.well-known/acme-challenge/bk7-6Ce4H0yJoDHtbaYLxIkx_UzJck2Mwfh5rolX9Jc -  -  - 
 I XX:44:20.243 sys AcmeFacade.java:188 qtp1275013351-161814 Handling request http://email.valence.nl/.well-known/acme-challenge/bk7-6Ce4H0yJoDHtbaYLxIkx_UzJck2Mwfh5rolX9Jc -  -  - 
 I XX:44:49.472 sys AcmeFacade.java:216 pool-1-thread-1 polling PendingOrder{domain='email.valence.nl', state=POLLING, order status=PENDING, order problem=null, order authorizations status=INVALID} -  -  - 
 I XX:44:50.300 sys AcmeFacade.java:223 pool-1-thread-1 challenge is invalid: PendingOrder{domain='email.valence.nl', state=POLLING, order status=INVALID, order problem=null, order authorizations status=INVALID} -  -  - 
 I XX:44:50.480 sys BrandingDomainService.java:392 pool-1-thread-1 Failed ordering ACME certificate: email.valence.nl -  -  -
6

Is this your own ACME client? It looks like your ACME client is not logging the order/authorization URLs, so it makes it hard to determine what’s going on.

The authorization URL is like this: https://acme-v02.api.letsencrypt.org/acme/authz-v3/xxxxxx , order URLs are like this: https://acme-v02.api.letsencrypt.org/acme/order/XXXX/YYYY and challenge URLs are like this: https://acme-v02.api.letsencrypt.org/acme/chall-v3/XXXX/YYYY

It is very unlikely that the the error message is actually null. More likely, the Java ACME client is not deserializing it correctly.

If you can print the raw URL, you can visit it in the browser, and you will see what the problem is. For example, if you click here.

7

Thanks, I see now.
We use acme4j library and for many, many other cases it works correctly. It is our fault that we don’t print errors which are on challenges.
We will update our logging and perhaps we will understand the issue.

8

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