Certificate spec missing commonName in dnsNames (ACME InvalidOrder) #1709
Description
When deploying the chart with tls.type=cert-manager, the generated Certificate manifest includes a commonName of metrics-server but does not include that value in the dnsNames list.
This causes cert-manager with ACME issuers (e.g., Let’s Encrypt) to reject the order with:
The CSR PEM requests a commonName that is not present in the list of dnsNames or ipAddresses.
If a commonName is set, ACME requires that the value is also present in the list of dnsNames or ipAddresses:
"metrics-server" does not exist in [metrics-server.kube-system, metrics-server.kube-system.svc, metrics-server.kube-system.svc.cluster.local]
Steps to reproduce:
- Deploy the chart with
tls.type=cert-managerusing an ACME ClusterIssuer. - Observe the CertificateRequest events.
Expected behavior:
The commonName should also be included in the dnsNames array to comply with ACME requirements.
Proposed fix:
Update the Certificate template to add:
dnsNames:
- {{ include "metrics-server.fullname" . }}
- {{ include "metrics-server.fullname" . }}.{{ .Release.Namespace }}
- {{ include "metrics-server.fullname" . }}.{{ .Release.Namespace }}.svc
- {{ include "metrics-server.fullname" . }}.{{ .Release.Namespace }}.svc.{{ .Values.tls.clusterDomain }}
so that the commonName is represented in dnsNames.