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
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.
