We used to distinguish these tokens using the azp claim, but this
claim does not appear on new azure oidc tokens, at least on some
configurations.
This change will try to load by audience (client id) if the token
contains an email, required for OIDC.
Azure caches tokens for 24h and we cannot issue a new certificate
for the same instance in that period of time.
The meaning of this parameter is to allow the signing of multiple
certificate in one instance. This is possible in GCP, because we
get a new token, and is possible in AWS because we can generate
a new one. On Azure there was no other way to do it unless you
wait for 24h.
Fixes#656
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.
All tests for the Authority failed because the test data
contains ECDSA keys. ECDSA keys are no crypto.Decrypter,
resulting in a failure when instantiating the Authority.
A server without TLS was added to serve the SCEP endpoints. According
to the RFC, SCEP has to be served via HTTP. The `sscep` client, for
example, will stop any URL that does not start with `http://` from
being used, so serving SCEP seems to be the right way to do it.
This commit adds a second server for which no TLS configuration is
configured. A distinct field in the configuration, `insecureAddress`
was added to specify the address for the insecure server.
The SCEP endpoints will also still be served via HTTPS. Some clients
may be able to work with that.
This commit also improves how the crypto.Decrypter interface is
handled for the different types of KMSes supported by step. The
apiv1.Decrypter interface was added. Currently only SoftKMS
implements this interface, providing a crypto.Decrypter required
for SCEP operations.
