Repository navigation
Constrain lifetime of signed certificate by remaining lifetime of parent certificates. #560
Description
- step-ca should transparently reduce the notAfter of any issued certificates to min(requested-notAfter, intermediate-notAfter, root-notAfter)
- If the notAfter is reduced, step-ca should log a warning: "Requested certificate expiration was reduced from to because leaf certificates cannot expire after [intermediate|root] certificate. You may need to issue a new [intermediate|root] with an extended lifetime."
- On CA startup, if now() + maxTLSCertDuration for any provisioner is >= or >= we should log a warning: "Configured maxTLSCertDuration for provisioner allows leaf certificate expirations after [intermediate|root] certificate expiration. Leaf certificate cannot outlive intermediate or root certificates. * * Certificate expirations will be automatically reduced to . You may need to issue a new [intermediate|root] with an extended lifetime."
- On the client side (in step), if the actual notAfter of the issued certificate doesn't match the requested notAfter, log a warning: "Issued certificate lifetime does not match requested lifetime. notAfter has been reduced to . Your CA may need a new [intermediate|root] with an extended lifetime."
From #381
Reacted by gwe32
Activity
dopey commentedon May 4, 2021
We should combine this other validation going up the chain (e.g. name constraints).
For validity window we should only constrain to the issuing certificate. Since recursively this should work up the chain.
Should we attempt to verify the full chain that has been configured at
step-cainit time?feat: Enforce issuer validity limits and warnings
aw1cks commentedon Nov 13, 2026
Implementation available in #2820, with client-side warning handling in smallstep/cli#1715. This covers issuance-time limits and warnings, but not the startup-warning item. One design point to resolve: the PR uses the earliest expiry across the configured issuing chain, whereas the later comment here suggests limiting only against the immediate issuer. Could maintainers confirm the preferred policy on the PR?