Auto DevOps failures in Let's Encrypt with long domain names
With a long domain name the autogenerated URL for an auto-devops app can break the cert management:
I1015 18:24:42.009889 1 sync.go:288] Error issuing certificate for **redacted**: error getting certificate from acme server: acme: urn:ietf:params:acme:error:malformed: Error finalizing order :: CN was longer than 64 bytes
It seems that the name generation needs to notice if the auto-generated name is too long for Let's Encrypt to handle.
Proposal
It seems that Let's Encrypt can happily handle these long URLs when they are used in as the Subject Alternative Name
and it only has a problem when used as Common Name (see https://community.letsencrypt.org/t/ssl-for-a-63-character-max-number-of-characters-domain-name-s/36387/14). So we can just hardcode a short SSL common name le.$AUTO_DEVOPS_BASE_DOMAIN and then add all the hosts as Subject Alternative Names. This way we don't need to change our strategy for generating domain names just yet.
I use your auto devops app helm chart as base for our own ones and I just reduced the character limit in the _helpers.tpl from trunc 64 to trunc 50. So far good enough and no trouble with cert-manager. The limitation is purely on letsencrypt (cert-manager default) side, which limits to 64 character including the domain.
I use your auto devops app helm chart as base for our own ones and I just reduced the character limit in the _helpers.tpl from trunc 64 to trunc 50. So far good enough and no trouble with cert-manager.
@adamlem yeah this is good information to know. I'm wondering though if you have a problem with the environment URLs being display wrong in GitLab though? If you truncate the URL so it's different to what GitLab thinks it is then some functionality in GitLab will be degraded. Or am I misunderstanding? The environment URL is also set in the CI YML.
@DylanGriffith link "Open live environment" in the environment overview is correct, so far I didn't discover any issues with it but I'm not using every functionality. We have our own central prometheus etc.
@DylanGriffith@Alexand do you happen to know of any other possible workarounds? For the customer in the linked ticket, the above suggestion hasn't worked, I'm afraid.
They provided the below excerpted, redacted logs:
I0118 02:31:31.338686 1 sync.go:288] Error issuing certificate for xyz-auto-deploy-tls: error getting certificate from acme server: acme: urn:ietf:params:acme:error:malformed: Error finalizing order :: CN was longer than 64 bytes
@DylanGriffith@adamlem The suggestion in #55820 (closed) (comment 128148458) doesn't seem to be truncating the fully qualified app name to the number of characters specified in the _helpers.tpl. I changed the trunc value under the appname, fullname and trackableappname from trunc 63 to trunc 53, however the app name still contains 63 characters.
Should the app name/environment URL be limited to the 53 characters after re-deploying with the modified values?
Have I missed something?