Giters

shred / acme4j

Java client for ACME (Let's Encrypt)

Home Page:https://acme4j.shredzone.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

AcmeJsonResource#update throws AcmeRetryAfterException even if resource is ready

probert94 opened this issue · comments

commented

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 validor 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.

commented

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.

commented

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

commented

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.

commented

Closing this issue, feel free to reopen if necessary.