See https://github.com/cert-manager/cert-manager/issues/5601
When referring to external issuers whose kind is not "Issuer" or
"ClusterIssuer" we log an error message thanks to a new check added in
a previous PR[1] which should only trigger for SelfSigned issuers.
The error previously looked like:
```text
"error"="invalid value \"x\" for issuerRef.kind. Must
be empty, \"Issuer\" or \"ClusterIssuer\""
```
After this PR, any CR with an issuer whose group or kind doesn't
match what's expected for a built-in issuer will be skipped
https://github.com/cert-manager/cert-manager/pull/5336
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
WIP: test other issuer kinds
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Due to a bug in controller-gen[1] certain paths are incorrectly split
and part of these paths can be interpreted as a numeric literal, which
will cause controller-gen to fail. We observe this as occasional test
flakes in the "verify-crds" target, when the tmpdir starts with a zero,
such as in "/tmp/tmp.0PFqFSHBID"
This commit attempts to avoid this bug by specifying a template for the
tmpdir we generate when verifying CRDs which doesn't include any "."
characters, which seem to be being split incorrectly.
[1] https://github.com/kubernetes-sigs/controller-tools/issues/734
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
cert-manager was not able to retry failed TPP certificates due to the
fact that TPP will not reset a given certificate that has a failed
enrollment status from a previous enrollment. More specifically,
cert-manager was getting stuck with either:
WebSDK CertRequest Module Requested Certificate
or
This certificate cannot be processed while it is in an error state.
Fix any errors, and then click Retry.
With vcert v4.23.0, a call to "reset" is made when one of these two
messages are found while polling for the certificate (i.e., while
calling vcert's RetrieveCertificate function).
Signed-off-by: Maël Valais <mael@vls.dev>
Previously it wasn't possible to set a custom CA bundle for an ACME
server, leading users to either patch the cert-manager system CA bundle
manually or else use SkipTLSVerify which is a security issue.
This adds CABundle for ACME, similar to what we have for Vault and
Venafi TPP issuers.
Longer term we'd like to have a more fully featured approach. It would
for example make sense to support loading CA bundles from ConfigMaps or
Secrets (similar to what we do for Vault issuers today), but for now this
change is the simplest change.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Clarifies language a little; makes it clearer that the bundle
should be base64 encoded. Previously it was slightly confusing
in that PEM certificates are themselves base64 encoded.
Also makes it clearer what our CABundle validation does and does not do
by adding a standalone validation function and tweaking the error
message for an invalid CA bundle.
Also updates validation to not print CA bundle for Vault issuer when the
bundle is invalid, since it won't help with debugging anything.
Currently the bundle is printed as byte values ("0x32, 0x58, 0x43...")
and in any case printing the whole bundle could be noisy if it's large
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>