Server does not support auto-renewal

[cowwoc]

Version 3.4.0

Per Order.autoRenewal()'s Javadoc, it enables auto renewal if supported by the CA. Yet, when I invoke it, I get this exception:

org.shredzone.acme4j.exception.AcmeNotSupportedException: Server does not support auto-renewal
	at org.shredzone.acme4j@3.4.0/org.shredzone.acme4j.OrderBuilder.create(OrderBuilder.java:343)

Expected behavior: If the server does not support auto-renewal then request a normal certificate.

Correct me if I'm wrong but I don't think that users care what mechanism the server uses to renew the certificate (manual or automatic) so long as it gets done.

[shred]

I think this behavior would be fatal.

You say: "CA, please give me an auto-renewing certificate."
The CA says: "Sorry, but I'm unable to do that."

The only reasonable reaction is to throw an exception.

If this conflict would be ignored, you would get a certificate that you would expect to auto-renew, but instead it would just expire in a couple of months.

[cowwoc]

The documentation currently reads:

Enables short-term automatic renewal of the certificate, if supported by the CA.

To me, this means that if the feature is not supported by the CA then nothing will happen. There is no indication in the Javadoc that an error will be thrown if this is not the case.

I was/am working under the assumption that end-users will run acme4j in a background thread regardless of the acme server implementation. So long as they have acme4j running in the background, they shouldn't care whether the server uses auto-renewal or not... it'll renew the certificate when and if it needs to.

That said, the way that the method is currently specified (forbidding the use of notBefore(), notAfter()) is not fully compatible with that interpretation... If my interpretation were correct, then I'd expect notBefore(), notAfter() to be allowed but treated as a suggestion that is ignored when auto-renewal is supported.

I think either interpretation is fine, but the documentation should probably be updated accordingly. Thank you in advance.

[shred]

To me, this means that if the feature is not supported by the CA then nothing will happen. There is no indication in the Javadoc that an error will be thrown if this is not the case.

It is a builder, and as such, it will first collect your parameters. Validation takes place as soon as .create() is invoked.

I was/am working under the assumption that end-users will run acme4j in a background thread regardless of the acme server implementation.

This is not what acme4j is intended to be. It is meant to help with the ACME protocol, which is already a lot of work in itself (it's more than just having an client auto-generated by swagger or so).

I intentionally decided against writing a service that does all the work of certificate creation and renewal. For that, I would need a framework (e.g. Spring) and some kind of persistence layer. As this project is a spare-time-one-man-show (and not something that is funded by any of the CAs involved), I really lack the time to do that.

So... If the CA supports auto-renewal, you can ask it to create an auto-renewing certificate, and you will get a location URL of a cert that is automatically updated by the CA. If the CA does not support it, you have to go through the renewal process on your own.

If my interpretation were correct, then I'd expect notBefore(), notAfter() to be allowed but treated as a suggestion that is ignored when auto-renewal is supported.

It is explicitly specified in RFC 8739 that "the optional notBefore and notAfter fields [...] MUST NOT be present in a STAR Order. If they are included, the server MUST return an error with status code 400 (Bad Request) and type malformedRequest."

[cowwoc]

I intentionally decided against writing a service that does all the work of certificate creation and renewal. For that, I would need a framework (e.g. Spring) and some kind of persistence layer. As this project is a spare-time-one-man-show (and not something that is funded by any of the CAs involved), I really lack the time to do that.

Fair enough. So the only remaining point of this issue would be to improve the documentation. It currently says that some action will take place if the server supports the capability. I would expect it to add that if the capability is not supported, it will result in the failure of the Order.