You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A boulder-ca instance currently can only issue certificates with a single defined validity period. With the current boulder-ca code, to offer different validity periods in addition to our current 90 day certs e.g. a short lived cert of 7 days, we would need to run a separate set of WFE, RA, and CA instances. Instead each certificate profile should control the validity period..
A boulder-ca today can only issue certificates with one specific lifetime due to the Expiry field being outside the purview of a certificate profile. The maxValidity in each certificate profile is only used to check if it's less than the CA's expiry field.
Why does this matter, doesn't a client CSR tell us what the lifetime should be? Well, yes, but also no. Inside ca.generateSerialNumberAndValidity, the CA silently drops the notBefore and notAfter from a client CSR and creates it own validity struct containing a notBefore and notAfter. The CA then passes that validity struct to ca.issuePrecertificate etc. This transformation of the notBefore and notAfter is what binds each profile, regardless of its configured maxValidity to the CA's expiry field.
I noticed this while writing a unit test for multiple certificate profile support. Here's an example short lived profile with my faulty assumption that MaxValidityPeriod would be used to calculate the certificate lifetime.
A boulder-ca instance currently can only issue certificates with a single defined validity period. With the current boulder-ca code, to offer different validity periods in addition to our current 90 day certs e.g. a short lived cert of 7 days, we would need to run a separate set of WFE, RA, and CA instances. Instead each certificate profile should control the validity period..
A boulder-ca today can only issue certificates with one specific lifetime due to the Expiry field being outside the purview of a certificate profile. The
maxValidity
in each certificate profile is only used to check if it's less than the CA's expiry field.Why does this matter, doesn't a client CSR tell us what the lifetime should be? Well, yes, but also no. Inside ca.generateSerialNumberAndValidity, the CA silently drops the notBefore and notAfter from a client CSR and creates it own validity struct containing a notBefore and notAfter. The CA then passes that validity struct to
ca.issuePrecertificate
etc. This transformation of the notBefore and notAfter is what binds each profile, regardless of its configuredmaxValidity
to the CA's expiry field.I noticed this while writing a unit test for multiple certificate profile support. Here's an example short lived profile with my faulty assumption that
MaxValidityPeriod
would be used to calculate the certificate lifetime.Here's a CA impl it was attached to from a setup function.
and a resulting error I received when trying to issue from this short lived profile.
The text was updated successfully, but these errors were encountered: