Technically the webhook request is a new request, so maybe the
`X-Request-ID` should not be set to the value of the original
request? But then the original request ID should be propageted
in the webhook request body, or using a different header.
The way the request ID is used in this functionality is actually
more like a tracing ID, so that may be an option too.
* move to use embed instead of a multi-line string
* add test to ensure all certificates are valid
* add test to ensure validity (no expired certificate)
This commit fixes a problem when the ca.json is truncated if the
encoding of the configuration fails. This can happen by adding a new
provisioner with bad template data.
Related to smallstep/cli#994
When changing the SCEP configuration it is possible that one
or both of the decrypter configurations required are not available
or have been provided in a way that's not usable for actual SCEP
requests.
Instead of failing hard when provisioners are loaded,
which could result in the CA not starting properly, this type of
problematic configuration errors will now be handled at usage
time instead.
This commit removes the regular expression check on OIDC usernames.
Although it is not recommended to use any character in a username,
it is possible to create and use them. The tool useradd has the flag
--badname and adduser has --allow-badname and --allow-all-names to
create new users with any character.
Moreover, it is possible to create any username with the rest of
provisioners.
Fixes#1436
Instead of relying on an intermediate `scep.Service` struct,
initialize the `scep.Authority` directly. This removes one redundant
layer of indirection.
With the introduction of certificate templates some certificate
validators and modifiers are not used anymore. This commit deletes the
ones that are not used.
Trying to get CRL to work on my environment I've been reading up on [RFC5280](https://www.rfc-editor.org/rfc/rfc5280#section-5.2.5) ... and the IDP to be marked as `Critical`. I hope I'm correct and that my understanding on how to mark the IDP is critical.
Looking at e.g. `3470b1ec57/x509util/extensions_test.go (L48)` makes me think so.
---
Hopefully the above change - if accepted - can get CRL's to work on my environment. If not we're at least one step closer.
This commit will ignore principals validation when an OIDC provisioner
is used. When the principals in the server does not match the principals
given the validation was failing, even if the proper principals were set
by templates or webhooks. With this change OIDC will not validate the
principals and just set the default ones (name, name@example.org) plus
the ones in the templates.
This commit also includes a change in the templates to allow to pass
a provisioner to the $(step path)/ssh/config template
Related to #807
This commit changes the parsing of root and federated roots to support
a bundle of certificates, this makes easier to configure a root rotation
when using helm charts, just appending the old root.
It supports renewing X.509 certificates when an RA is configured with stepcas.
This will only work when the renewal uses a token, and it won't work with mTLS.
The audience cannot be properly verified when an RA is used, to avoid this we
will get from the database if an RA was used to issue the initial certificate
and we will accept the renew token.
Fixes#1021 for stepcas
This commit adds some changes to PR #731, some of them are:
- Add distribution point to the CRL
- Properly stop the goroutine that generates the CRLs
- CRL config validation
- Remove expired certificates from the CRL
- Require enable set to true to generate a CRL
This last point is the principal change in behaviour from the previous
implementation. The CRL will not be generated if it's not enabled, and
if it is enabled it will always be regenerated at some point, not only
if there is a revocation.
Renew was not replicating exactly the subject because extra names
gets decoded into pkix.Name.Names, the non-default ones should be
added to pkix.Name.ExtraNames. Instead of doing that, this commit
sets the RawSubject that will also keep the order.
Fixes#1106
The first super admin subject can now be provided through the
`--admin-subject` flag when initializing a CA.
It's not yet possible to configure the subject of the first
super admin when provisioners are migrated from `ca.json` to the
database. This effectively limits usage of the flag to scenarios
in which the provisioners are written to the database immediately,
so when `--remote-management` is enabled. It currently also doesn't
work with Helm deployments, because there's no mechanism yet to
pass this type of option to the Helm chart.
This commit partially addresses https://github.com/smallstep/cli/issues/697
Provisioners stored in the CA configuration file are
automatically migrated to the database.
Currently no cleanup of the provisioners in the
configuration file yet. In certain situations this
may not work as expected, for example if the CA can't
write to the file. But it's probalby good to try it, so
that we can keep the configuration state of the CA consistent.
