0

So I'm having difficulty getting my LE wildcard cert setup on my EKS cluster (was running K8s 0.18, but just upgraded to 0.19). My understanding is I need to do a DNS challenge which I'm trying to get setup and I'm hitting a major roadblock on. I started by creating the cert-manager namespace and ran the kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml command to install v1.2 of cert-manager.

That installed successfully so I went on to create an AWS user that has the proper permissions to modify the Route53 config with this configuration.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "route53:GetChange",
            "Resource": "arn:aws:route53:::change/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Resource": "arn:aws:route53:::hostedzone/*"
        },
        {
            "Effect": "Allow",
            "Action": "route53:ListHostedZonesByName",
            "Resource": "*"
        }
    ]
}

Then I created my secret, ClusterIssuer and Certificate w/ these parameters.

apiVersion: v1
kind: Secret
metadata:
  name: prod-route53-credentials-secret
type: Opaque
stringData:
  secret-token: [aws-user-secret]
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: [my-email]
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - selector:
        dnsZones:
          - "example.com"
      dns01:
        route53:
          region: us-east-1
          hostedZoneID: [route53-hosted-zone-id]
          accessKeyID: [aws-user-key-id]
          secretAccessKeySecretRef:
            name: prod-route53-credentials-secret
            key: secret-token
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: le-crt
spec:
  secretName: tls-secret
  issuerRef: 
    kind: ClusterIssuer
    name: letsencrypt-prod
  commonName: example.com
  dnsNames:
    - "example.com"
    - "*.example.com"

I applied that in both the default and cert-manager namespaces to see if one would work. Everything looks like it created properly, but I'm not seeing the challenge key being added to our DNS, and I'm not seeing the https route on the app work either. How can I further debug this?

One error I did notice when I run kubectl logs -n cert-manager -f -l app=cert-manager --all-containers is: reflector.go:127] external/io_k8s_client_go/tools/cache/reflector.go:156: Failed to watch *v1.CertificateRequest: failed to list *v1.CertificateRequest: conversion webhook for cert-manager.io/v1alpha2, Kind=CertificateRequest failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": x509: certificate signed by unknown authority

One thing I can definitely use help with is debugging the issue because even though it looks like everything created, I'm not sure where to go to find any errors that might help shed light on the problem.

Chris Kelly
  • 73
  • 1
  • 10
  • are you creating the tls-secret on your own ? Or allowing cert manager to create one in your cluster ? – Tushar Mahajan Feb 18 '21 at 17:59
  • I'm allowing cert manager to create it. – Chris Kelly Feb 18 '21 at 18:29
  • try referring this https://stackoverflow.com/questions/58423312/how-do-i-test-a-clusterissuer-solver/58436097?noredirect=1#comment103215785_58436097. , maybe this helps – Tushar Mahajan Feb 18 '21 at 18:37
  • That looks like a HTTP challenge, not DNS. Do you have any idea how I can at least go about debugging where the issue is? I think that's the hardest part right now. – Chris Kelly Feb 19 '21 at 16:25
  • well, it automatically did the DNS verification thing for me, let's give a try, try removing the info of AWS route 53 from the DNS , I guess it shall automatically look for resolving the Domain name to the IP and verification will be done, you can just keep the CNAMEs mapped to public IP in route 53, give it a try – Tushar Mahajan Feb 19 '21 at 17:18

0 Answers0