Cert-manager: Webhook validation rejects long-named non-ACME certificates

[hobti01]

Describe the bug:
Certificate with long CN is rejected even if Issuer is not Let's Encrypt.

admission webhook "certificates.admission.certmanager.k8s.io" denied the request: spec.dnsNames[0]: Too long: must have at most 64 characters

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: token-store-tls
spec:
  dnsNames:
  - my-long-name-token-store-0.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-1.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-2.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-3.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-4.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store
  - my-long-name-token-store-peer
  - my-long-name-token-store.default.svc.cluster.local
  - my-long-name-token-store-peer.default.svc.cluster.local
  duration: 8760h0m0s
  issuerRef:
    kind: ClusterIssuer
    name: local-root-ca
  organization:
  - MyOrg
  renewBefore: 1440h0m0s
  secretName: token-store-tls

Expected behaviour:
Limitations of Let's Encrypt apply only to Let's Encrypt issuers. Not all ACME issuers, or all Certificates. Although the maximum length of a hostname (RFC-1123) is 63 characters, the maximum length of a domain name is much longer.

Steps to reproduce the bug:
Deploy with webhook admission controller
Create non-ACME certificate with long name

Anything else we need to know?:

• Workaround 1: Disable the webhook
• Workaround 2: Specify a short name for the commonName or dnsNames[0], and longer names as SubjectAlternativeNames

...
kind: Certificate
spec:
  dnsNames:
  - my-long-name-token-store
  - my-long-name-token-store-0.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-1.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-2.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-3.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-4.my-long-name-token-store-peer.default.svc.cluster.local
  - my-long-name-token-store-peer
  - my-long-name-token-store.default.svc.cluster.local
  - my-long-name-token-store-peer.default.svc.cluster.local
...

Environment details::

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

/kind bug

[cpu]

Limitations of Let's Encrypt apply only to Let's Encrypt issuers. Not all ACME issuers, or all Certificates. Although the maximum length of a hostname (RFC-1123) is 63 characters, the maximum length of a domain name is much longer.

I don't have a horse in this race and can understand it would be frustrating to have new validation break existing use cases but I wanted to add a quick clarifying note. This isn't a Let's Encrypt limitation but applies to all publicly trusted CAs. It comes from the primary RFC that governs the web PKI, RFC 5280. Specifically it's the ASN.1 module in Appendix A that defines ub-common-name for the x509 v3 certificate profile to be 64 bytes. This is a more relevant citation for this case than RFC-1123. Because the baseline requirements in turn reference RFC 5280 compliance any publicly trusted CA operating under the BRs cannot issue a certificate with a CN longer than 64 characters. dNSName type Subject Alternative Name extensions are used instead for the (as you point out, valid) DNS names longer than 64 characters.

[hobti01]

OK, fantastic that there is a spec and it is followed!

Thank you for your incredible memory or time to research :D

Closing with thanks for all the great work and helpful community!

[cpu]

For an internal PKI I'd recommend removing the Subject CN field entirely from your CSRs / Certificates and only relying on SANs. The reason that Let's Encrypt specifically can't do this yet is a longer story involving long-tail compatibility and additional baseline requirements restrictions that don't typically apply to an internal PKI. This thread has more gory detail if you're curious.

[hobti01]

OK, but AFAIK cert-manager then uses the first entry in dnsNames as the Subject name, which is how we started on this thread.

[cpu]

OK, but AFAIK cert-manager then uses the first entry in dnsNames as the Subject name, which is how we started on this thread.

I thought that was just for the ACME issuer, not for externally generated certificates but I'm admittedly out of my depth here.

[hobti01]

Looks like all CSRs: https://github.com/jetstack/cert-manager/blob/release-0.9/pkg/util/pki/csr.go#L38-L46

[cpu]

I think it's a valid feature request to want to be able to issue CN-less certificates for non-LE issuers.