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>
this is disabled for all issuers except selfsigned and CA. the intention
is to pave the way for adding maxPathLen support later.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
this function doesn't appear to be used anywhere, which makes it a
little confusing when trying to work out how the checks are done in the
e2e tests.
given that we encourage people not to import cert-manager as a module
and that anyone who does is likely not to use functions in the test
directory, it seems safe enough to remove this rather than deprecating
it.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
there seems to be justification for setting GOSUMDB to a universal value
here, but setting GOPROXY doesn't seem to provide value here
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
The Gateway CRD has to be installed, meaning that the CRDs may be
installed after cert-manager. We don't want cert-manager to crash in
that case; instead, we let the user know that cert-manager will keep
retrying looking for the CRDs with this message on startup:
controller.go:181] cert-manager/controller/build-context "msg"="the
Gateway API CRDs do not seem to be present, cert-manager will keep
retrying watching for them"
The user then sees the following message printed (using an exponential
back-off):
reflector.go:167: Failed to watch *v1alpha1.Gateway: failed to list
*v1alpha1.Gateway: the server could not find the requested resource
(get gateways.networking.x-k8s.io)
Signed-off-by: Maël Valais <mael@vls.dev>
Note that the gateway-shim is only half the work for supporting the
Gateway API in cert-manager. The other half is the HTTP01 solver
support, which is still worked on.
The Gateway API in cert-manager is releases as an experimental feature
and needs to be enabled manually with the following flag:
--controllers=*,gateway-shim
All the annotations supported by ingress-shim are also supported by
gateway-shim, with some exceptions:
"acme.cert-manager.io/http01-ingress-class"
This annotation is not supported on the Gateway resource. Although the
Gateway resource also has a "gatewayClass" field, we will need to add
another field instead of "ingress-class" to avoid confusion with the
ingress-shim.
"acme.cert-manager.io/http01-edit-in-place"
This annotation is not supported because it is specific to some ingress
controllers like ingress-gce.
"kubernetes.io/tls-acme"
This annotation is not supported because it is a behavior inherited from
kube-lego and we chose not to keep this behavior with the Gateway API.
Unlike the ingress-shim, you can reuse the same Secret name in multiple
TLS configurations on the same Gateway resource.
The ingress-shim now shows the exact location of the duplicate
secretName when the user gives the same secretName in two separate TLS
blocks.
Signed-off-by: Maël Valais <mael@vls.dev>
Co-authored-by: Jake Sanders <i@am.so-aweso.me>
