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.
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.
- Read `preferred_username` from token
- Add `preferred_username` to the default Usernames
- Check the `admin` array for admin groups that the user might belong to
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.
This adds a new KMS, SSHAgentKMS, which is a KMS to provide signing keys
for issuing ssh certificates signed by a key managed by a ssh-agent. It
uses the golang.org/x/crypto package to get a native Go implementation
to talk to a ssh-agent.
This was primarly written to be able to use gpg-agent to provide the
keys stored in a YubiKeys openpgp interface, but can be used for other
setups like proxying a ssh-agent over network.
That way the signing key for ssh certificates can be kept in a
"sign-only" hsm.
This code was written for my employer Intinor AB, but for simplicity
sake gifted to me to contribute upstream.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This changes adds a new option `iidRoots` that allows a user to
define one or more certificates that will be used for AWS IID
signature validation.
Fixes#393
