* Add OID translation for mandatory DC component
* Used extensively in LDAP certificates, also required by rfc5280
* Add support for UID, mentioned in LDAP RFC
* solves https://github.com/cert-manager/cert-manager/issues/5582
Signed-off-by: SpectralHiss <houssem.elfekih@jetstack.io>
This removes all .bazel and .bzl files, and a bunch of scripts relating
to bazel, now that it's been entirely replaced.
There are still a few places where traces could be removed, but this
removes the brunt of the bazel stuff that remains.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
This change adds the ability to express certificate duration using
the Kubernetes CSR spec.expirationSeconds field alongside the existing
approach of using the experimental.cert-manager.io/request-duration
annotation. Both approaches are supported as the expirationSeconds
field requires Kubernetes v1.22+.
Signed-off-by: Monis Khan <mok@vmware.com>
Since this test requires setup before it can successfully run,
we define it as an integration test and move it here so that on a
fresh checkout a user can always run `go test ./pkg/...` and expect that
it would succeed.
Also involves:
- Exporting the VersionChecker and adding NewWithConfig to enable
testing
- Some comment changes
- A change to the type returned by New(); see
https://github.com/golang/go/wiki/CodeReviewComments#interfaces
Ideally I'd not add `NewFromClient` but I think it's the most minimal
change and is preferable to publicly exporting `VersionChecker.client`.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Some clusters may have failed pods that are not garbage collected. These
pods should not be considered when determining version numbers.
Signed-off-by: John Chadwick <86682572+johnwchadwick@users.noreply.github.com>
roots are handled differently because they're their own CAs
also adds test cases for each of:
- a lone leaf
- a lone intermediate
- a lone root
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Fixes when the certificate chain does not have a root CA,
in which case the chain should contain all available intermediates
and ca.crt should contain the rootmost certificate.
Co-authored-by: Josh Van Leeuwen <joshua.vanleeuwen@jetstack.io>
Signed-off-by: Wilson Júnior <wilsonpjunior@gmail.com>
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
see also https://github.com/jetstack/cert-manager/issues/4142
EncodeX509Chain checked for self-signed certs by comparing the subject
and issuer of the cert in question, which is invalid since it's
perfectly fine for those to match.
the correct behavior is to use cert.CheckSignatureFrom(cert). this bug
was exposed in 1.4 when ParseSingleCertificateChain started using
EncodeX509Chain in the critical path of several issuers; when end-users
had leaf certificates with subjects matching their issuer's subject, the
bug was triggered.
includes newly written tests for EncodeX509Chain and a test for
ParseSingleCertificateChain
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Note that using ed25519 on the public internet is not currently
recommended, since it's not widely supported. You'd likely not be able
to use an Ed25519 cert with an ACME issuer today.
Ed25519 certs might be useful for internal PKI, though - an ed25519 CA
issuer, say - or for testing ed25519 certs before they become more
widely available on the public internet. They're not currently
supported by Vault, Venafi or ACME (Letsencrypt) issuers.
Signed-off-by: Anner J. Bonilla <abonilla@hoyosintegrity.com>
Signed-off-by: Anner J. Bonilla <annerjb@gmail.com>
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
