Partial revert of #4981 / 62eae60. Some HSMs have a small number
of slots and require storing multiple keys per slot (differentiated
by keyID, which we now look up based on the public key per #4992).
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
This mocks out the signer type rather than mocking out the pkcs11
object, making the test less dependent on the internals of our
pkcs11helpers package.
Part of refactorings related to #4918.
We had some duplicated code related to opening the PKCS#11 session and
generating a signer, so I pulled it out into a separate function. This
function also takes an issuer so it can verify that the public key
matches what's expected.
Our PKCS11 config sections fall into two categories:
- Those used for generating keys, where the HSM is both an input and an
output, storing the resulting key in a specified slot.
- Those used for signing certs, where the HSM is an input.
This creates dedicated config structs for these two, reducing
duplication in defining overall config structs. This also makes
defining test cases involving these config structs much more concise.
Fixes#4915
This ended up taking a lot more work than I expected. In order to make the implementation more robust a bunch of stuff we previously relied on has been ripped out in order to reduce unnecessary complexity (I think I insisted on a bunch of this in the first place, so glad I can kill it now).
In particular this change:
* Removes bhsm and pkcs11-proxy: softhsm and pkcs11-proxy don't play well together, and any softhsm manipulation would need to happen on bhsm, then require a restart of pkcs11-proxy to pull in the on-disk changes. This makes manipulating softhsm from the boulder container extremely difficult, and because of the need to initialize new on each run (described below) we need direct access to the softhsm2 tools since pkcs11-tool cannot do slot initialization operations over the wire. I originally argued for bhsm as a way to mimic a network attached HSM, mainly so that we could do network level fault testing. In reality we've never actually done this, and the extra complexity is not really realistic for a handful of reasons. It seems better to just rip it out and operate directly on a local softhsm instance (the other option would be to use pkcs11-proxy locally, but this still would require manually restarting the proxy whenever softhsm2-util was used, and wouldn't really offer any realistic benefit).
* Initializes the softhsm slots on each integration test run, rather than when creating the docker image (this is necessary to prevent churn in test/cert-ceremonies/generate.go, which would need to be updated to reflect the new slot IDs each time a new boulder-tools image was created since slot IDs are randomly generated)
* Installs softhsm from source so that we can use a more up to date version (2.5.0 vs. 2.2.0 which is in the debian repo)
* Generates the root and intermediate private keys in softhsm and writes out the root and intermediate public keys to /tmp for use in integration tests (the existing test-{ca,root} certs are kept in test/ because they are used in a whole bunch of unit tests. At some point these should probably be renamed/moved to be more representative of what they are used for, but that is left for a follow-up in order to keep the churn in this PR as related to the ceremony work as possible)
Another follow-up item here is that we should really be zeroing out the database at the start of each integration test run, since certain things like certificates and ocsp responses will be signed by a key/issuer that is no longer is use/doesn't match the current key/issuer.
Fixes#4832.
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.
Jacob Hoffman-Andrews