* Allows the ceremony tool to add the `onlyContainsCACerts` flag to the
`IssuingDistributionPoint` extension[1] for CRLs.
* Add a lint to detect basic usage of this new flag.
* Add a helper function which doesn't (yet) exist in golang
x/crypto/cryptobyte named `ReadOptionalASN1BooleanWithTag` which
searches for an optional DER-encoded ASN.1 element tagged with a given
tag e.g. onlyContainsUserCerts and reports values back to the caller.
* Each revoked certificate in the CRL config is checked for is `IsCA` to
maintain conformance with RFC 5280 Section 6.3.3 b.2.iii [2].
> (iii) If the onlyContainsCACerts boolean is asserted in the
> IDP CRL extension, verify that the certificate
> includes the basic constraints extension with the cA
> boolean asserted.
Fixes https://github.com/letsencrypt/boulder/issues/7047
1. https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5
2. https://datatracker.ietf.org/doc/html/rfc5280#section-6.3.3
Replace capital letters with lowercase letters in markdown fragments for
compatibility with various markdown renderers. For example, Github
happily accepts fragments as-is, but vscode does not.
Fixes https://github.com/letsencrypt/boulder/issues/6722
- Change generate CSR to only use a Subject and signer in creation
- Add a method to certProfile to return subject
- Validate that CSR input does not contain unwanted values
- Update tests and documentation about ceremony
Fix: #5318
Generated keys have the same label on both the private and public key
objects. When looking up keys for signing, the label is used to find the
public key.
This moves x509Signer from cmd/ceremony into pkcs11helpers. It also
adds helper functions getPublicKeyID and getPrivateKey, copied and
adapted from pkcs11key. These act as counterparts to the existing
GetRSAPublicKey and GetECDSAPublicKey, which go from an object handle
to a Go public key object (and are used after key generation).
Fixes#4918
Initially this was going to just be a bool on the `intermediate` type,
but there is enough different in terms of what is generated that I think
it makes sense to add a completely separate type. Internally they share
the same config, since basically everything else is the same (apart from
a few constraints on what fields can be populated in the profile).
This additionally fixes a bug where we weren't actually validating
root/intermediate/key configs.
Fixes#4741
Adds support for qualified CPS policies to root/intermediate generation.
This changes the existing policy-oids fields to a policies field which covers both bare policies and id-qt-cps qualified policies.
Fixes#4724
Merges gen-ca and gen-key into a single tool that can be used to complete a key/certificate generation ceremony. The driving idea here is that instead of having to write out multiple long commands in a specific order in order to complete a ceremony a configuration file is fed to a single binary. This config file contains all of the information needed to complete the ceremony, and can be easily tested outside of the secure environment before hand without fear of later typing a command/flag incorrectly etc.
The tooling works against the test hardware I have (there are minimal changes to the actual PKCS#11 code behind the scenes). Specific attention should be given to the documentation, and the general UX of the tool.
Fixes#4639 and fixes#4667.
James Renken