Implement ACME Renewal Information (ARI) #85
Conversation
|
I think there might be some kind of a flaky race condition with the Pebble tests that also needs investigating. I'm seeing the occasional spurious error from an order's identifiers not matching the CSR identifiers 🤔 |
|
Why is it useful for the identifier type to live in pki-types? What would the downside be if it living in this crate? |
I flip flopped a bit. Initially I was thinking there was a reason to involve
I figured this out locally. It's authz reuse & a logic bug in the test finalization logic carried forward from the |
|
I rebased this on top of #86 and implemented the review feedback so far. |
Will fix this & the other nits from self-review shortly. Out of juice for today |
|
Yup, won't take a look at it until tomorrow either. |
I think this is in pretty good shape now. I'd like to hold merging it until I have a chance to verify it works with LE's staging server but I should be able to do that in the next few days. |
Also add more detail to the pre-reqs for running the Pebble tests.
This type holds the BASE64 URL-safe encoding of a certificate's DER encoded authority key information (AKI) ext's keyIdentifier field, and the BASE64 URL-safe encoding of a certificate's raw DER encoded serial number. Ser/der is done by consuming/emitting the pair of encoded fields, '.' separated. For now this can only be constructed directly from raw DER and the caller is responsible for extracting the right values from a certificate. Subsequent commits will offer a way to construct one from certificate DER using an optional x509-parser dependency.
This error type can be used when a feature is requested that we know the ACME server doesn't support (e.g. based on the absence of a URL from the directory resource).
Instead of constructing a `NewOrder` instance by populating the `pub identifiers` field directly, use `NewOrder::new()` and make the internal fields private. This will let us switch to a builder-model for future customization.
Done! I also bumped the crate version to reflect the breaking changes. Moving on to testing with a real server. |
By optionally specifying a `CertificateIdentifier` when constructing a `NewOrder` it's possible to indicate to the ACME CA that the order is a replacement for a pre-existing certificate that was previously ordered. When accepted, an order created in this way will echo back a `replaces` field with the serialized `CertificateIdentifier` the order replaces.
Add an optional, non-default, feature for `x509-parser` that allows constructing `CertificateIdentifier` instances from certificate DER.
This will allow using the issued certificate for further testing (e.g. revocation, replacement order).
In the near future it may contain IP address identifiers.
This will support making it easier for each test to construct its own identifiers up-front.
This will make it ergonomic to test things like order replacement by calling `replaces()` on the `NewOrder` before providing it to `test()`.
Also activate the optional `x509-parser` feature for the CI invocation.
Adds a new `Account.renewal_info()` function that takes a `CertificateIdentifier` and returns the `RenewalInfo` the CA suggests for that certificate. Requires opting in to a `time` dependency feature.
Updates the ARI integration test to revoke the initial certificate, and then verifying the ARI info suggests immediate replacement before replacing it.
Notably we have to avoid activating the `fips` feature since it won't build in the docs env.
This ended up being a bit of a rabbit hole and ultimately resulted in one code change. Fetching renewal info works great, but creating replacement orders was throwing an error because the reflected order doesn't have a matching Previously in
If we sent With Let's Encrypt staging and production I never get back a reflected From my cursory look at Boulder, there doesn't seem to be a place to set that field at all. The internal I'll file an upstream issue but for now I've relaxed the check in 9d7563b and suggest we can merge this as-is. @djc WDYT? |
|
cpu
changed the title
This branch implements ACME Renewal Information based on
draft-08. While not yet a proposed standard RFC this draft is nearly at that stage, and has been deployed by Let's Encrypt (and I believe Google as well).Support brings a few new bits of API surface:
CertificateIdentifiertype that uniquely identifies a certificate for ARI compatible servers. This requires parsing specific certificate fields to construct, and so without taking a dependency users are expected to provide the relevantpki_types::Derdata pre-extracted from a certificate.x509-parserdependency we offer a way to go frompki_types::CertificateDer<_>to aCertificateIdentifierwhen thex509-parserdependency feature is activated.DirectoryUrlstype gets a newrenewal_infofield to track the optional ARI endpoint used to signal the ACME server supports ARI.timedependency feature is activated, theAccountstruct gains a newrenewal_info()function that accepts aCertificateIdentifierand returnsRenewalInfothat the caller can use to determine when to replace the identified certificate. This function returns an error if the CA doesn't support ARI.NewOrderstruct gains a new optionalreplaces(cert_id: CertificateIdentifier)function that can be used to indicate an order is a replacement for a previous order. CAs might use this information to give more generous rate limits, or to know when it's safe to revoke a previously issued certificate due to imposed compliance reasons. LikeAccount.renewal_info()theAccount.new_order()function will error if provided aNewOrderwith areplacementvalue if the ACME CA doesn't support ARI.