Just a heads up for anyone else playing with ARI support in their clients. As far as I'm aware, Google is the only other free ACME CA to have an ARI implementation so far. But they're still using draft-01 at the moment and sending draft-03 cert ID values generates an HTTP 400 error.
Since I already had the draft-01 code, I added it as a fallback if the draft-03 request fails. I haven't gotten around to implementing the replaces field in new orders yet, but presumably that will also fail if it gets sent to Google.
Do we have any Google people who frequent here that could give us an indication about when their ARI implementation might get updated as well?
Also for the Google folk, the link to the ARI spec here, https://pki.goog/services/, is broken due to an HTML typo. <a heref= instead of <a href=.
Good point! For info, Certify The Web updated it's ARI support to the current draft and supports Replaces in the order payload, but if the order fails repeatedly it will skip the Replaces field. Ran into this because existing deployments had the CertID in the old format and also if you do CA fallback between different CAs then the replaces field is CA specific and will potentially derail your cert order if you try to use it with the wrong CA.
Regarding Google or any invalid ARI checks though, if you just catch and log the error then move on it's fine, best efforts when the goal posts move etc.
I can confirm that support for draft-03 is on Google Trust Services roadmap for this quarter. I will check with the team member working on ARI on Monday and try to give a more precise date of when we expect it to land.
Also, thank you very much for reporting the bug on our website. A quick fix has been sent out for review.
I found that when it doens't know about issure part it errors 404(when server changes so try to attach prod certid to staging etc, and looking at boulder code it's status will be whatever underlaying error throws.
I think only safe way is on any error try without ari once
The certificate's Serial Number field has the hexadecimal bytes 00:87:65:43:21 as its DER encoding (note the leading zero byte to ensure the serial number remains positive despite the leading 1 bit in 0x87). The base64url encoding of those bytes is AIdlQyE=
Some of my certificates from GTS happen to have serial numbers which DER encoding starts with zero byte. I get 400 Bad Request when I query their renewal info - but if I omit the initial null byte in encoded serial number during ARI CertID construction, I'm able to get renewal info successfully.
Am I reading spec wrong or is it bug in GTS implementation?
Considering this is a draft spec (and continually changing) with different adoption rates, do you think it would make sense for the spec to require ARI payloads to contain a version id?
It's more than just the checking-for-renewal-info payload, it's also things like how the client should indicate that a certificate has been replaced. Currently the logic is just "Does the directory have a renewalInfo" but in retrospect adding a little more detail about versions to the directory might have been sense. Though at this point, I suspect that there's hope that there won't be any further major revisions.
Really support for ARI and version info for it are just one more thing that should be in some sort of "capabilities" advertised by the server (maybe in the directory metadata), about what CSR hash algorithms are allowed, what key types and lengths are allowed (for both leaf certificates and for account keys), how notBefore/notAfter requests are handled, maybe some rate limit info, etc. (as we have discussed previously).
You're right that it would have been nice for there to be some sort of ARI version advertisement. This is my first IETF document, and I wrote it with an eye towards people adopting the final version of it, not towards people implementing, deprecating, and re-implementing various draft versions along the way. It sucks that the IETF doesn't seem to have better support for and best-practices to offer first-time authors. Also, ACME itself doesn't have any support for capability or version advertisement, so it's unclear what this even would have looked like.
But at this point it's basically "too late" -- the draft has largely settled, and at the last IETF meeting we agreed to do a Working Group Last Call after the next version (draft -04) is published. That version only contains minor editorial changes on top of the current draft -03.
So again, apologies, but this is where we're at and at this point I doubt it's worth changing the draft spec just to make handling additional (unlikely) drafts easier.
If you foresee any future changes though - be it via this RFC or a future one that replaces or augments - please consider adding a ,"v":"{id}" to the payload. It would only add 8 bytes, and be immensely useful.
Adding a version to the renewalInfo payload would only help clients that can already formulate a correct request -- it wouldn't help clients that are still using the OCSP-based CertID construction. To truly help all clients, the version info would have to be in the directory object. And of course, clients would need to know to look for it, which clients that have already implemented draft-01 but not updated since then would not... You see why this is nontrivial.
I mean, when changing the format from the draft-01 OCSP structure to the AKI-serial structure, one could have also changed the directory entry, from renewalInfo to renewalInformation or renewalInfo-draft-03 or whatever. That could make it easier for a server to support multiple versions, and for a client to know which version(s) a server was implementing. I suppose one could change the entry name, even still, for the final final final released version.
But if there are no more big changes expected, then I agree that it's probably not worth doing anything more at this point.
Are there any statistics available for how often an ARI request using the old draft-01 structure is hitting the Let's Encrypt servers? (Or the draft-03 structure, for that matter?)
Thanks again @damisanet for reporting the issue with the serial number. It was indeed due to the padded zero byte from the DER encoding. When decoding this serial number, we added a check to the length of the decoded bytes to see if it fit our expected format and failed to account for the extra zero byte in the DER encoding. On the integration test side, our ARI client code also failed to DER encode the serial number before formatting the request, hiding the error.
Code that fixes the issue should be rolling out to production tomorrow.
