AcmeJsonResource#update throws AcmeRetryAfterException even if resource is ready
probert94 opened this issue · comments
I recently added ZeroSSL as an ACME provider in a project I am working on and noticed that the creation process often fails.
After debugging I found, that ZeroSSL includes the "Retry-After" header, even if the challenge is already fullfilled and this causes acme4j to throw a AcmeRetryAfterException
when calling AcmeJsonResource#update
.
My current workaround is to still check the status using getStatus
when this exception is thrown. If the status is valid
or invalid
I'll continue otherwise I'll wait and update the resource again.
The problematic code is in AcmeJsonResource#update
(Line 127). handleRetryAfter
is called without checking the status first.
AcmeJsonResource#update
will still update the status even if the AcmeRetryAfterException
is thrown. So actually it's correct to check getStatus()
first, and ignore the exception if the status has reached valid
or invalid
. I rather think it's a bit strange from ZeroSSL to send a Retry-After
header even if the resource has reached a terminal state.
Anyway, I am currently working on a new release that will help you in many aspects.
- It will support ZeroSSL out of the box.
- The example has been changed to correctly handle the Retry-After header.
- The whole
AcmeRetryAfterException
mechanism is a legacy from acme4j v2 that can be handled more elegantly now.
The new version is almost completed and should be released in the next couple of days.
Thank you for the information.
I rather think it's a bit strange from ZeroSSL
I was not sure if this is a valid response or, as you said, a strange one. I had another look at the RFC and it only mentions "Retry-After" in combination with the "processing" state. So I notified ZeroSSL regarding this, let's see what they say.
It will support ZeroSSL out of the box.
What exactly do you mean with that?
Other then this unexpeced behavior we had no real problems with ZeroSSL in combination with this library.
Thanks
I rather think it's a bit strange from ZeroSSL
I was not sure if this is a valid response or, as you said, a strange one. I had another look at the RFC and it only mentions "Retry-After" in combination with the "processing" state. So I notified ZeroSSL regarding this, let's see what they say.
Technically it's possible IMHO. However, what is the purpose to say: "the resource is finally valid, but ask again in 30 seconds"? 😉
It will support ZeroSSL out of the box.
What exactly do you mean with that?
There will be an acme://zerossl.com
URI instead of https:...
.
Other then this unexpeced behavior we had no real problems with ZeroSSL in combination with this library.
Thank you! That's good to know.
As I said, in the next version the Retry-After handling will be much easier.
Closing this issue, feel free to reopen if necessary.