Create a Kubernetes Secret with AWS credentials or configure IRSA for cert-manager's service account to call Route53
Define a ClusterIssuer with ACME DNS01 using Route53: spec.acme.solvers[0].dns01.route53 with region, hostedZoneID, and either accessKeyID/secretAccessKeySecretRef or an empty accessKeyID to use IRSA
Apply the ClusterIssuer: 'kubectl apply -f clusterissuer.yaml' and confirm it becomes Ready with 'kubectl get clusterissuer letsencrypt-prod -o jsonpath={.status.conditions[0].type}'
Create a Certificate resource in the target namespace: spec.dnsNames=['*.example.com'], spec.issuerRef.kind=ClusterIssuer, spec.secretName=wildcard-example-com-tls
Watch the Order and Challenge resources: 'kubectl get challenges -A -w' — cert-manager creates a TXT record in Route53, waits for DNS propagation, and ACME validates it
Once the Certificate status shows Ready=True, the TLS secret is populated; reference it in Ingress or Gateway resources
Known gotchas
DNS01 requires that the TXT record propagates to the authoritative DNS servers before ACME validates; high-TTL or slow-propagating zones can cause challenge timeouts — set the cert-manager DNS01 recursive nameservers to a fast resolver with '--dns01-recursive-nameservers'
ClusterIssuers are cluster-scoped but Certificate resources that reference them must set issuerRef.kind=ClusterIssuer not Issuer; using Issuer kind with a ClusterIssuer name silently creates a not-found error
Wildcard certificates issued via DNS01 cover only one level (*.example.com does not cover sub.sub.example.com); request explicit SANs if deeper subdomains are needed
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp