Cert-manager: Add ca.crt to TLS secret generated by ACME issuers

[ajpauwels]

Is your feature request related to a problem? Please describe.
The ca.crt field is added to the TLS secret generated by CA issuers, but is null for ACME issuers.

Describe the solution you'd like
The Issuer uses the Link header returned by the ACME protocol as defined by the ACME standard to fetch the issuer's cert and places it inside the TLS secret under the ca.crt key.

ACME standard
The Link header is mentioned in Section 6.5 Certificate Issuance of the ACME standard draft. Refer to the last paragraph on page 30 here: https://tools.ietf.org/html/draft-ietf-acme-acme-02

Environment details (if applicable):

• Kubernetes version (e.g. v1.10.2): v1.12
• Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): AKS
• cert-manager version (e.g. v0.4.0): v0.7.0
• Install method (e.g. helm or static manifests): static

/kind feature

[munnerz]

If this is something we are able to obtain from the ACME server (and it sounds like that is possible), then a +1 from me on this! 😄

If anyone is interested in putting together a PR for this, it'd be greatly appreciated 😄 it may require some changes to our ACME client to expose enough information for us to determine what to use. We'll also need to somehow 'passback' this information via the Order resource. Perhaps having a new field, caBytes (or similar) that sits alongside the existing order.status.certificate field?

[rolfdalhaug]

Hi

I'm not sure if this is related to an issue we're experiencing but would welcome some insight. We've implemented a ACME Issuer which has created a certificate which all checks out using SSL Server Test at SSL Labs. We can connect with SSL for browser connections etc. The issue we're having is when trying a connection with node (specifically Realm.io Data Adapter) we're getting a "The server certificate was not signed by any root certificate" "Verify return code: 21 (unable to verify the first certificate)". We're new to kubernetes / ingess SSL but doing some reading this seems to be an issue with the ca.crt?.. is this correct?.. On checking the secret we do have a 'null' ca.crt.

Are you able to advise on what the issue is / how to resolve?..

Thanks

[cpu]

If this is something we are able to obtain from the ACME server (and it sounds like that is possible)

If the OP means the root certificate and not an intermediate it isn't possible. ACME makes no provisions for communicating roots: these are meant to be present on the relying party systems out of band.

The Link header is mentioned in Section 6.5 Certificate Issuance of the ACME standard draft. Refer to the last paragraph on page 30 here: https://tools.ietf.org/html/draft-ietf-acme-acme-02

Note that draft-02 is extremely old and doesn't match up with Let's Encrypt's ACME v1 API or ACME v2. Also the Link headers were for following from an end entity certificate to the intermediate(s) that issued it, not the root. The full chain (minus the root) is always present in the response to a POST-as-GET for the order certificate URL in RFC 8555.

[ajpauwels]

Sorry for the late follow-up on this but @cpu is totally right. The tls.crt field contains the entire chain, from the leaf cert to the intermediate cert (not the root cert, but all I need is an intermediate cert). That chain is all I needed to complete TLS verification. If you require splitting off the leaf cert from the intermediate cert, here's a short snippet to alias that can do that on most systems:
csplit -f tls- -b "%02d.crt.pem" -s -z "$1" '/-----BEGIN CERTIFICATE-----/' '{1}'

Closing as the intermediate certs are already provided and root certs cannot be retrieved according to the standard.

[davgordo]

I respectfully disagree with the conclusion of this issue. It's well understood that the ACME spec itself does not explicitly support the retrieval of an issuer's root CA certificate. However the ca.crt key in certificate secrets doesn't necessarily need to represent the top-level root. It just needs to represent the issuing authority, which could be an intermediate.

Clearly the issuing intermediate can be derived [1] [2]. But these tricks represent an operational burden. Cert-manager could at least optionally support automatic population of the ca.crt key in the case of ACME issuers, based on the intermediate.

In my opinion the most important benefit of populating ca.crt for ACME issuers is that it provides a consistency (to the secret consumer) regardless of the type of issuer. There are use cases for consuming the ca.crt key (clearly, or else it wouldn't exist). The issuer type is purely irrelevant to the validity of those use cases.

Please consider re-opening this issue, or if it is more appropriate to create a new issue, I'm happy to do that.

[1] https://github.com/jetstack/cert-manager/issues/1571#issuecomment-486661887
[2] https://github.com/goharbor/harbor-helm/issues/261#issuecomment-504938813

[wichert]

For what it's worth having an empty ca.txt key makes it needless difficult to use ejabberd with cert-manager managed certificates: ejabberd will not start if ca.crt is present but invalid.

[aranair]

Also, not un-related, the empty field that ends up in the k8s secret ca.crt: null also prevents the k8s secret from being modified/copied to any other namespaces (because it fails validation).

[XanderAtBackboneSystems]

Also related, using istio (1.4.2) with cert-manager and ingress-sds will not work due to the missing ca.crt with the following log line:

failed load server cert/key pair from secret <SECRET-NAME>: server cert or private key is empty