Cert-manager: 63-character limit on http01 auth service name, possibly labels

Created on 2 Apr 2018  Â·  7Comments  Â·  Source: jetstack/cert-manager

/kind bug

What happened:

Tried to issue a certificate for a fairly long domain name.

Certs issue for other domain names just fine but got the following error:

I0402 18:08:09.045613       1 sync.go:242] Error preparing issuer for certificate: error presenting acme authorization for domain "nginx-php.endorsements.hotfix-revamp-admin-product-review.qa.prlx.io": error ensuring http01 challenge service: Service "cm-nginx-php-endorsements-hotfix-revamp-admin-product-r-http-gojor" is invalid: [metadata.name: Invalid value: "cm-nginx-php-endorsements-hotfix-revamp-admin-product-r-http-gojor": must be no more than 63 characters, metadata.labels: Invalid value: "nginx-php.endorsements.hotfix-revamp-admin-product-review.qa.prlx.io": must be no more than 63 characters, spec.selector: Invalid value: "nginx-php.endorsements.hotfix-revamp-admin-product-review.qa.prlx.io": must be no more than 63 characters]

What you expected to happen:

The cert to be issued - I understand the 63-character limitations. These look to have been previously addressed elsewhere: #93

The difference appears to be that the limit is being run into not on the generated ingress name but the name of the service for http01 auth, i.e. the whole DNS name.

How to reproduce it (as minimally and precisely as possible):

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: nginx-php-endorsements-hotfix-revamp-admin-product-r-http
  namespace: endorsements-qa
spec:
  acme:
    config:
    - domains:
      - nginx-php.endorsements.hotfix-revamp-admin-product-review.qa.prlx.io
      http01:
        ingress: ""
        ingressClass: nginx
  commonName: nginx-php.endorsements.hotfix-revamp-admin-product-review.qa.prlx.io
  dnsNames: null
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt-prod
  secretName: https-some-certificate
kinbug

Most helpful comment

Hum.. I just ran into this issue with 0.6.2. It looks like it's due to a label cert-manager sets, so hitting kubernetes label limit:

E0227 23:11:11.994628       1 controller.go:185] orders controller: Re-queuing item "aaaa-2019-02-22-xxxx-yyyyyy/aaaa-2019-02-22-xxxx-yyyyyy-gateway.aws.us-east-1.zzzz.example.com-2133156609" due to error processing: invalid label value: "aaaa-2019-02-22-xxxx-yyyyyy/aaaa-2019-02-22-xxxx-yyyyyy-gateway.aws.us-east-1.zzzz.example.com-2133156609": must be no more than 63 characters

All 7 comments

A bit more digging on this suggests that currently the 63-character limit applies to the domain name being used for http01.

309 also switches to use an adler32 hash for domain & token in order to track these resources, which should resolve this 😄

@munnerz Is the fixed rolled out in helm chart? I'm using stable/cert-manager v0.4.8 and still getting the error:
certificates controller: Re-queuing item "monitoring/prometheus" due to error processing: error presenting acme authorization for domain "prometheus-old.g-fix-gke-pipel.dev.gcp.platform.yyy.xxxxxxxx.com": error ensuring http01 challenge service: Service "cm-prometheus-zndhx" is invalid: [metadata.labels: Invalid value: "prometheus-old.g-fix-gke-pipel.dev.gcp.platform.yyy.xxxxxxxxx.com": must be no more than 63 characters, spec.selector: Invalid value: "prometheus-old.g-fix-gke-pipel.dev.gcp.platform.yyy.xxxxxxxx.com": must be no more than 63 characters]

No, the fix is not in a released tag of cert manager yet. A new release
will come in the next couple of weeks, or in the meantime the :canary image
tag is pushed from master, but may change/break things at any time (ie
outside of our versioning guarantees).

On Tue, 17 Apr 2018 at 19:16, Dhawal Patel notifications@github.com wrote:

@munnerz https://github.com/munnerz Is the fixed rolled out in the helm
chart? I'm using stable/cert-manager v0.4.8 and still getting the error:

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/jetstack/cert-manager/issues/425#issuecomment-382091254,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbPzV_BEUl5BcJxvf5Q6MH0Y8gCDW2ks5tpjGEgaJpZM4TD3r3
.

I've opened #492 to test/ensure we can support domains longer than 63 chars.

It's worth noting however, that a single DNS domain 'segment' has a limit of 63 characters (as per the ACME spec).

If you attempt to request a certificate for a domain that contains a subdomain that's >63 chars, the following message will be printed:

Error creating order: acme: urn:ietf:params:acme:error:malformed: Error creating new order :: DNS label is too long.

If you request a domain that is >63 chars, but none of its constituent segments are greater than 63 chars long, then it should work (after the patch in #309). #492 should verify this for us 😄

Hum.. I just ran into this issue with 0.6.2. It looks like it's due to a label cert-manager sets, so hitting kubernetes label limit:

E0227 23:11:11.994628       1 controller.go:185] orders controller: Re-queuing item "aaaa-2019-02-22-xxxx-yyyyyy/aaaa-2019-02-22-xxxx-yyyyyy-gateway.aws.us-east-1.zzzz.example.com-2133156609" due to error processing: invalid label value: "aaaa-2019-02-22-xxxx-yyyyyy/aaaa-2019-02-22-xxxx-yyyyyy-gateway.aws.us-east-1.zzzz.example.com-2133156609": must be no more than 63 characters

Have the same issue on 0.8.0

Was this page helpful?
0 / 5 - 0 ratings