Before this commit, EAB keys could be used CA-wide, meaning that
an EAB credential could be used at any ACME provisioner. This
commit changes that behavior, so that EAB credentials are now
intended to be used with a specific ACME provisioner. I think
that makes sense, because from the perspective of an ACME client
the provisioner is like a distinct CA.
Besides that this commit also includes the first tests for EAB.
The logic for creating the EAB JWS as a client has been taken
from github.com/mholt/acmez. This logic may be moved or otherwise
sourced (i.e. from a vendor) as soon as the step client also
(needs to) support(s) EAB with ACME.
Instead of using `step-ca login` we will use a new token provided
as a flag to configure and start linkedca. Certificates will be kept
in memory and refreshed automatically.
Replaces the authority adminDB with a new impmentation that users the
linkedca client to retrieve the data.
Note that this implementation still hardcodes the endpoint to localhost.
- added a bit of validation to admin create and update
- using protojson where possible in admin api
- fixing a few instances of admin -> acme in errors
Instead of using the defaultPublicKeyValidator a new validator called
publicKeyMinimumLengthValidator has been implemented that uses a
configurable minimum length for public keys in CSRs.
It's also an option to alter the defaultPublicKeyValidator to also
take a parameter, but that would touch quite some lines of code. This
might be a viable option after merging SCEP support.
Only when a SCEP provisioner is enabled, the SCEP endpoints
will now be available.
The SCEP endpoints will be served on an "insecure" server,
without TLS, only when an additional "insecureAddress" and a
SCEP provisioner are configured for the CA.
