If you are developing a client, this change to authorization creation may be of interest to you.
Soon (within the next few weeks) we’ll turn on a Boulder flag that will enable transparent reuse of existing, valid authorizations. This shouldn’t require any changes to clients, and we’ve tested it using Certbot without issue.
If you ask Boulder to create a new authorization, and Boulder already has a valid authorization for the same FQDN, and there is more than a day left before that authorization expires, Boulder will simply return the existing authorization object.
To work around some client quirks, Boulder will no longer reject POSTs to authorization objects that are already valid. That way, clients that create a new authorization and then POST to it without checking its status will still succeed.
As always we’ll turn this on in staging first, and I’ll post again here once it’s enabled there. I’ll also post again once it’s enabled in prod.
I’m sure this is what was meant, but just to confirm and spell it out, the authorization has to belong to the subscriber account that’s making the request right?
If account A asks to create an authz for example.com, succeeds in validating it, and then account B comes along and wants an authz for example.com too, that should result in a fresh authz regardless of this setting.
This isn’t really a backend question, but maybe a client person can chime in: Do popular clients like certbot report (at least in their verbose/ debug mode) that they were able to proceed without validation (because they got an authz that was already validated) ? I can imagine that when debugging client issues on this site it will be useful to understand if this special case is happening to them or not.
There has been some confusion stemming from this change and so I wanted to follow-up with a quick note about challenge status.
If your client creates an authorization object and expects to solve multiple challenges it will appear as though some of the challenges are stuck in a pending state. Once the first challenge for an authorization is satisfied and valid the overall authorization changes to valid and no subsequent challenges will be updated. E.g. if I create an authorization and complete the http-01 challenge the authorization will be marked valid and the dns-01 and sni-01 challenges will remain in a pending state.
The best approach from a client perspective is to check the status of the authorization object rather than individual challenge objects. That way if the authorization object is already in “valid” state the client can cease further processing of challenges.