snowdrop/godaddy-webhook

Cert Manager Godaddy Webhook performing ACME challenge using DNS record

godaddy-webhook's Issues

Issue with Ingress finding Certificate generated using this webhook

I am using cert-manager with my EKS cluster to generate Lets Encrypt certificates for my ALB using this webhook. While the certificate is generated just fine, the Ingress cannot find it and fails to start the ALB with the error

Failed build model due to ingress: prod/prod-ingress: no certificate found for host: *.domain.com

Here is the certificate

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: letsencrypt-staging
  namespace: prod
spec:
  secretName: letsencrypt-staging
  renewBefore: 240h
  dnsNames:
    - "*.domain.com"
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

And this is created just fine as I mentioned earlier

k get certificate -n prod
NAME                  READY   SECRET                AGE
letsencrypt-staging   True    letsencrypt-staging   27m

Here is the ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prod-ingress
  namespace: prod
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/listen-ports:  '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/subnets: subnet-ef84a5b6,subnet-a3177fc6 
    cert-manager.io/cluster-issuer: letsencrypt-staging
spec:
  tls:
    - hosts:
        - "*.domain.com"
      secretName: letsencrypt-staging
  rules:
    - host: portal.domain.com
      http: 
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-server-svc
                port:
                  number: 80

which fails with the following error

Name:             prod-ingress
Labels:           <none>
Namespace:        prod
Address:          
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  letsencrypt-staging terminates *.domain.com
Rules:
  Host                    Path  Backends
  ----                    ----  --------
  portal.domain.com  
                          /   web-server-svc:80 (XXXX:80)
  
Annotations:              alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS":443}]
                          alb.ingress.kubernetes.io/scheme: internet-facing
                          alb.ingress.kubernetes.io/subnets: subnet-ef84a5b6,subnet-a3177fc6
                          alb.ingress.kubernetes.io/target-type: ip
                          cert-manager.io/cluster-issuer: letsencrypt-staging
                          kubernetes.io/ingress.class: alb
Events:
  Type     Reason            Age                From     Message
  ----     ------            ----               ----     -------
  Warning  FailedBuildModel  3s (x13 over 23s)  ingress  Failed build model due to ingress: prod/prod-ingress: no certificate found for host: *.domain.com

Why is the ingress unable to find the certificate, yet they are both in the same namespace?

Error presenting challenge: secrets "godaddy-api-key" not found

Hello, I am trying to get a wildcard certificate but I'm encountering an issue I can't seem to be able to fix.

Once arriving to the challenge, I get stuck with the following error

Error presenting challenge: secrets "godaddy-api-key" not found

Althought the secret is currently in the same namespace

 kg secret -n media
NAME                             TYPE                 DATA   AGE
wildcard-example-com-zb4ln         Opaque               1      13m
godaddy-api-key                  Opaque               1      10m

 kg challenges.acme.cert-manager.io -n media
NAME                                         STATE     DOMAIN      AGE
wildcard-example-com-1-2845708639-3787760156 pending example.com   12m

I'm not sure what could cause the secret not to be seen by the ACME Challenge

Include the all resources yaml file part of the github workflow release process

TODO

Include the all resources yaml file part of the github workflow release process

Challenge CR reports an Unexpected HTTP status: 401 from GoDaddy

Issue

When we create a Certificate CR to request to get from Godaddy a certificate using DNS-01, the challenge created by the certificate manager to issue a ACME reqyuest with Godaddy returns the following error

reason: 'Unable to check the TXT record: ### Unexpected HTTP status: 401'

Example of CR

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: snowdrop-dev
  labels:
    app: ca-cert
  namespace: snowdrop-site
spec:
  authorizationURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/265604611626
  dnsName: snowdrop.dev
  issuerRef:
    kind: Issuer
    name: letsencrypt-prod-snowdrop-dev
  key: soOO...0DywA
  solver:
    dns01:
      webhook:
        config:
          apiKeySecretRef:
            key: token
            name: godaddy-api-key
          production: true
          ttl: 600
        groupName: acme.mycompany.com
        solverName: godaddy
    selector:
      dnsNames:
      - snowdrop.dev
      - '*.apps.ocp.snowdrop.dev'
  token: -0odX-rE5T...NCrLA
  type: DNS-01
  url: https://acme-v02.api.letsencrypt.org/acme/chall-v3/265604611626/eKNU3Q
  wildcard: false
status:
  presented: false
  processing: true
  reason: 'Unable to check the TXT record: ### Unexpected HTTP status: 401'
  state: pending

The problem is not related to the Godaddy API and Secret keys used as we can get a certificate/keys using Lego tool

GODADDY_API_KEY=dLD...GtDHq \
GODADDY_API_SECRET=jL44...GgTps \
lego --email [email protected] --dns godaddy --domains console2-openshift-console.apps.ocp.snowdrop.dev run
2023/09/19 08:57:17 No key found for account [email protected]. Generating a P256 key.
2023/09/19 08:57:17 Saved key to /Users/cmoullia/temp/lego/.lego/accounts/acme-v02.api.letsencrypt.org/[email protected]/keys/[email protected]
2023/09/19 08:57:18 Please review the TOS at https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf
Do you accept the TOS? Y/n
Y
2023/09/19 08:57:27 [INFO] acme: Registering account for [email protected]
!!!! HEADS UP !!!!

Your account credentials have been saved in your Let's Encrypt
configuration directory at "/Users/cmoullia/temp/lego/.lego/accounts".

You should make a secure backup of this folder now. This
configuration directory will also contain certificates and
private keys obtained from Let's Encrypt so making regular
backups of this folder is ideal.
2023/09/19 08:57:27 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Obtaining bundled SAN certificate
2023/09/19 08:57:27 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/265836647926
2023/09/19 08:57:27 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Could not find solver for: tls-alpn-01
2023/09/19 08:57:27 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Could not find solver for: http-01
2023/09/19 08:57:27 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: use dns-01 solver
2023/09/19 08:57:27 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Preparing to solve DNS-01
2023/09/19 08:57:29 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Trying to solve DNS-01
2023/09/19 08:57:29 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Checking DNS record propagation using [10.38.5.26:53 10.11.5.19:53]
2023/09/19 08:57:31 [INFO] Wait for propagation [timeout: 2m0s, interval: 2s]
2023/09/19 08:57:31 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Waiting for DNS record propagation.
2023/09/19 08:57:33 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Waiting for DNS record propagation.
2023/09/19 08:57:36 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Waiting for DNS record propagation.
2023/09/19 08:57:38 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Waiting for DNS record propagation.
2023/09/19 08:57:40 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Waiting for DNS record propagation.
2023/09/19 08:57:42 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Waiting for DNS record propagation.
2023/09/19 08:57:48 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] The server validated our request
2023/09/19 08:57:48 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Cleaning DNS-01 challenge
2023/09/19 08:57:49 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] acme: Validations succeeded; requesting certificates
2023/09/19 08:57:50 [INFO] [console2-openshift-console.apps.ocp.snowdrop.dev] Server responded with a certificate.

Notice: I suspect a Cert Manager + LetsEncrypt DNS-01 ACME challenge issue OR a Godaddy Webhook issue . to be investigated

Set the Logging Level as new Helm parameter

Todo

Set the different parameters able to configure the logrus Logger. Add new parameters like; level, format and timestamp as new Helm values

Separate the CI from the publish job

TODO

Comment from #40

Error: Command failed: DOCKER_BUILDKIT=1 docker buildx build -f Dockerfile -t [quay.io/snowdrop/cert-manager-webhook-godaddy:pr-40-0da9b20](http://quay.io/snowdrop/cert-manager-webhook-godaddy:pr-40-0da9b20) -t [quay.io/snowdrop/cert-manager-webhook-godaddy](http://quay.io/snowdrop/cert-manager-webhook-godaddy):latest --platform linux/amd64,linux/arm64 --push .

I normally separate my CI job from the publish job. Publish job could after PR is merged:
[quay.io/snowdrop/cert-manager-webhook-godaddy:latest](http://quay.io/snowdrop/cert-manager-webhook-godaddy:latest)

CI build (before PR is merged) maybe a git reference tag instead of latest.

@bordenit

YAML is invalid

Trying to install the application results in this error

$ helm install -n cert-manager godaddy-webhook ./deploy/helm
Error: INSTALLATION FAILED: YAML parse error on godaddy-webhook/templates/rbac.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key

there are several syntax errors in the yaml file to the point I'm not really sure what some of it is supposed to be

Bump kubebuilder-tools to 1.24 to been able to install the tools for Darwing ARM

TODO

Bump kubebuilder-tools to 1.24.x to been able to install the tools for Darwing ARM

Bump version to 1.5 or 1.6 as v1.2 is old and not supported

Request

Bump version to 1.5 or 1.6 as v1.2 is old and not supported

Test fails "Unauthorized : Could not authenticate API key/secret"

Issue

Check why test is failing

 TEST_ZONE_NAME=example.com. go test .
I0124 11:04:18.792981   50890 request.go:968] Request Body: {"kind":"Namespace","apiVersion":"v1","metadata":{"name":"basic-present-record","creationTimestamp":null},"spec":{},"status":{}}
I0124 11:04:18.793342   50890 round_trippers.go:423] curl -k -v -XPOST  -H "Accept: application/json, */*" -H "Content-Type: application/json" -H "User-Agent: godaddy-webhook.test/v0.0.0 (darwin/amd64) kubernetes/$Format" 'http://127.0.0.1:52351/api/v1/namespaces'
I0124 11:04:18.813686   50890 round_trippers.go:443] POST http://127.0.0.1:52351/api/v1/namespaces 201 Created in 20 milliseconds
I0124 11:04:18.813719   50890 round_trippers.go:449] Response Headers:
I0124 11:04:18.813725   50890 round_trippers.go:452]     Content-Type: application/json
I0124 11:04:18.813730   50890 round_trippers.go:452]     Date: Mon, 24 Jan 2022 10:04:18 GMT
I0124 11:04:18.813734   50890 round_trippers.go:452]     Content-Length: 311
I0124 11:04:18.813848   50890 request.go:968] Response Body: {"kind":"Namespace","apiVersion":"v1","metadata":{"name":"basic-present-record","selfLink":"/api/v1/namespaces/basic-present-record","uid":"feac3c42-7cfc-11ec-8f9c-acde48001122","resourceVersion":"41","creationTimestamp":"2022-01-24T10:04:18Z"},"spec":{"finalizers":["kubernetes"]},"status":{"phase":"Active"}}
I0124 11:04:21.968608   50890 round_trippers.go:423] curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: godaddy-webhook.test/v0.0.0 (darwin/amd64) kubernetes/$Format" 'http://127.0.0.1:52351/api/v1/namespaces/basic-present-record/secrets/dummy'
I0124 11:04:21.969653   50890 round_trippers.go:443] GET http://127.0.0.1:52351/api/v1/namespaces/basic-present-record/secrets/dummy 200 OK in 1 milliseconds
I0124 11:04:21.969676   50890 round_trippers.go:449] Response Headers:
I0124 11:04:21.969681   50890 round_trippers.go:452]     Content-Type: application/json
I0124 11:04:21.969685   50890 round_trippers.go:452]     Date: Mon, 24 Jan 2022 10:04:21 GMT
I0124 11:04:21.969689   50890 round_trippers.go:452]     Content-Length: 652
I0124 11:04:21.969738   50890 request.go:968] Response Body: {"kind":"Secret","apiVersion":"v1","metadata":{"name":"dummy","namespace":"basic-present-record","selfLink":"/api/v1/namespaces/basic-present-record/secrets/dummy","uid":"fff4706a-7cfc-11ec-8f9c-acde48001122","resourceVersion":"46","creationTimestamp":"2022-01-24T10:04:20Z","annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{},\"name\":\"dummy\",\"namespace\":\"basic-present-record\"},\"stringData\":{\"token\":\"\\u003cGODADDY_KEY:GODADDY_SECRET\\u003e\"},\"type\":\"Opaque\"}\n"}},"data":{"token":"PEdPREFERFlfS0VZOkdPREFERFlfU0VDUkVUPg=="},"type":"Opaque"}
I0124 11:04:22.331042   50890 wait.go:344] Returning discovered zone record "example.com." for fqdn "example.com."
I0124 11:04:22.678065   50890 round_trippers.go:423] curl -k -v -XDELETE  -H "Accept: application/json, */*" -H "User-Agent: godaddy-webhook.test/v0.0.0 (darwin/amd64) kubernetes/$Format" 'http://127.0.0.1:52351/api/v1/namespaces/basic-present-record'
I0124 11:04:22.683054   50890 round_trippers.go:443] DELETE http://127.0.0.1:52351/api/v1/namespaces/basic-present-record 200 OK in 4 milliseconds
I0124 11:04:22.683078   50890 round_trippers.go:449] Response Headers:
I0124 11:04:22.683088   50890 round_trippers.go:452]     Content-Type: application/json
I0124 11:04:22.683095   50890 round_trippers.go:452]     Date: Mon, 24 Jan 2022 10:04:22 GMT
I0124 11:04:22.683111   50890 round_trippers.go:452]     Content-Length: 359
I0124 11:04:22.683166   50890 request.go:968] Response Body: {"kind":"Namespace","apiVersion":"v1","metadata":{"name":"basic-present-record","selfLink":"/api/v1/namespaces/basic-present-record","uid":"feac3c42-7cfc-11ec-8f9c-acde48001122","resourceVersion":"47","creationTimestamp":"2022-01-24T10:04:18Z","deletionTimestamp":"2022-01-24T10:04:22Z"},"spec":{"finalizers":["kubernetes"]},"status":{"phase":"Terminating"}}
--- FAIL: TestRunsSuite (9.36s)
    fixture.go:116: started apiserver on "http://127.0.0.1:52351"
    --- FAIL: TestRunsSuite/Conformance (3.89s)
        --- FAIL: TestRunsSuite/Conformance/Basic (3.89s)
            --- FAIL: TestRunsSuite/Conformance/Basic/PresentRecord (3.89s)
                util.go:61: skipping file "testdata/godaddy/README.md" with unrecognised extension
                util.go:70: created fixture "basic-present-record"
                suite.go:37: Calling Present with ChallengeRequest: &v1alpha1.ChallengeRequest{UID:"", Action:"", Type:"", DNSName:"example.com", Key:"123d==", ResourceNamespace:"basic-present-record", ResolvedFQDN:"cert-manager-dns01-tests.example.com.", ResolvedZone:"example.com.", AllowAmbientCredentials:false, Config:(*v1beta1.JSON)(0xc000716798)}
                suite.go:40: expected Present to not error, but got: could not create record [{"type":"TXT","name":"cert-manager-dns01-tests","data":"123d==","ttl":600}]; Status: 401; Body: {"code":"UNABLE_TO_AUTHENTICATE","message":"Unauthorized : Could not authenticate API key/secret"}
FAIL
FAIL    github.com/snowdrop/godaddy-webhook     10.086s
FAIL

Missing permissions for webhook deployment

The helm chart generated godaddy-webhook clusterrole is missing this rule to work (tested on OpenShift 4.15):

- apiGroups:                                                                                                                                                                                      
  - ""                                                                                                                                                                                            
  resources:                                                                                                                                                                                      
  - configmaps                                                                                                                                                                                    
  verbs:                                                                                                                                                                                          
  - get                                                                                                                                                                                           
  - watch                                                                                                                                                                                         
  - list

Create CI/CD for helm chart deployment

The helm chart can be installed without any issues, the problem arises when some CD tools (e.g. ArgoCD) need to deploy this helm, they need it properly packaged.

To solve this issue, it would be beneficial to have a Github Action to publish the packaged helm chart into the gh-pages branch that would be published on github.io as GitHub Page.

Error presenting challenge cannot create resource "godaddy" in API group "acme.amprajin.in" at the cluster scope

Error presenting challenge: godaddy.acme.amprajin.in is forbidden: User "system:serviceaccount:cert-manager:cert-manager" cannot create resource "godaddy" in API group "acme.amprajin.in" at the cluster scope

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # ACME Server
    # prod : https://acme-v02.api.letsencrypt.org/directory
    # staging : https://acme-staging-v02.api.letsencrypt.org/directory
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # ACME Email address
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-staging # staging or production
    solvers:
    - selector:
        dnsNames:
        - '*.amprajin.in'
      dns01:
        webhook:
          config:
            apiKeySecretRef:
              name: godaddy-api-key
              key: token
            production: true
            ttl: 600
          groupName: acme.amprajin.in
          solverName: godaddy

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-amprajin-in
spec:
  secretName: wildcard-amprajin-in-tls
  renewBefore: 240h
  dnsNames:
  - '*.amprajin.in'
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Challenge does not succeed

Hi there!

First of all thanks for making this webhook available to the community!

I tried the steps documented in the readme, but for some reason the challenge never succeeds. I'm not exactly sure whether it is due to some misconfiguration or due to a bug.

First some information about what I installed:

AKS Kubernetes Cluster (AKS)

CertManager 1.7.2

GoDaddy Webhook

• I used the main branch and applied the changes in the open PR to patch the Helm files. (#10)
• I then built the docker image and published the helm chart on our internal helm chart repo.

Deployment
We use Argo CD to deploy the helm charts

Resources

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-azure-aisot-ch
spec:
  secretName: wildcard-azure-aisot-ch-tls
  renewBefore: 240h
  dnsNames:
    - '*.aisot.ch'
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

apiVersion: v1
kind: Secret
metadata:
  name: godaddy-api-key
type: Opaque
stringData:
  token: {{ .Values.godaddy.token }}

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # ACME Server
    # prod : https://acme-v02.api.letsencrypt.org/directory
    # staging : https://acme-staging-v02.api.letsencrypt.org/directory
    server: https://acme-v02.api.letsencrypt.org/directory
    # ACME Email address
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - selector:
          dnsNames:
            - '*.aisot.ch'
        dns01:
          webhook:
            config:
              apiKeySecretRef:
                name: godaddy-api-key
                key: token
              production: true
              ttl: 600
            groupName: acme.aisot.ch
            solverName: godaddy

The main Error I see is the following:
When querying the SOA record for the domain '_acme-challenge.aisot.ch.' using nameservers [10.0.0.10:53], rcode was expected to be 'NOERROR' or 'NXDOMAIN', but got 'SERVFAIL'

I also see some errors in the log files. Files are attached.

I have to admit I'm kinda lost. Any suggestion would be highly appreciated. I think the webhook is not even called. At least I don't see anything in the dns config.

Thanks,
Roger

cert-manager-webhook.txt
godaddy-webhook.txt
cert-manager-cainjector.txt
cert-manager.txt

Need more priviledge to open port 443 in godaddy-webhook pod

Running in OCP 4.x, it seems that when the godaddy-webhook pod starts, it cannot bind to port 443 because it doesn't have the right to do it.
To overcome this, I added the user godaddy-webhook in the anyuid scc but it would be prefereble not to do this:
oc adm policy add-scc-to-user anyuid -z "godaddy-webhook"

Would there be a way to modify some clusterRole so the user could do that?

Failed to install godaddy-webhook

I wasn't able to install the webhook following the instructions.
The returned error is:

Error from server (InternalError): error when creating "deploy/webhook-all.yml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded

In detail:

• environment: LKE cluster
• cert-manager v1.10.1 installed

command

kubectl apply -f deploy/webhook-all.yml --validate=false

response

serviceaccount/godaddy-webhook created
clusterrole.rbac.authorization.k8s.io/godaddy-webhook created
clusterrolebinding.rbac.authorization.k8s.io/godaddy-webhook created
rolebinding.rbac.authorization.k8s.io/godaddy-webhook:webhook-authentication-reader created
clusterrole.rbac.authorization.k8s.io/godaddy-webhook:domain-solver created
clusterrolebinding.rbac.authorization.k8s.io/godaddy-webhook:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/godaddy-webhook:domain-solver created
clusterrole.rbac.authorization.k8s.io/godaddy-webhook:flowcontrol-solver created
clusterrolebinding.rbac.authorization.k8s.io/godaddy-webhook:flowcontrol-solver created
service/godaddy-webhook created
deployment.apps/godaddy-webhook created
apiservice.apiregistration.k8s.io/v1alpha1.acme.mycompany.com created
Error from server (InternalError): error when creating "deploy/webhook-all.yml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded
Error from server (InternalError): error when creating "deploy/webhook-all.yml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded
Error from server (InternalError): error when creating "deploy/webhook-all.yml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded
Error from server (InternalError): error when creating "deploy/webhook-all.yml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded

Godaddy API doesn't appear to be called

I've installed cert-manager and the godaddy-webhook. After following the directions in the README, I can see my certificate request getting created. However, it doesn't appear that the GoDaddy API is ever called.

Is there a way to check logs/status on the webhook to see if its getting the DNS challenge back from LetsEncrypt and making the call to the GoDaddy API?

Error presenting challenge: the server could not find the requested resource

Hello everyone,

i have a problem requesting a certificate for a domain of mine. i have made the following configuration:

Certificate:

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: <NAME>
  namespace: cert-manager
spec:
  secretName: <NAME>
  renewBefore: 240h
  issuerRef:
    name: letsencrypt-production
    kind: ClusterIssuer
  commonName: "<NAME>"
  dnsNames:
  - "<NAME>"
  - "<NAME>"

Issuer:

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <EMAIL>
    privateKeySecretRef:
      name: letsencrypt-production
    solvers:
      - selector:
          dnsZones:
            - "<NAME>"
        dns01:
          webhook:
            config:
              apiKeySecretRef:
                name: godaddy-api-key
                key: token
              production: true
              ttl: 600
            groupName: acme.<NAME>
            solverName: godaddy

SecretKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: godaddy-api-key
  namespace: cert-manager
type: Opaque
stringData:
  token: <TOKEN>

At first i got the error that a resource could not be created for the group i specified. The exact error looked like this:

Error presenting challenge: godaddy.acme.<NAME> is forbidden: User "system:serviceaccount:cert-manager:cert-manager" cannot create resource "godaddy" in API group "acme.<NAME>" at the cluster scope 

I then created a role-binding to set authorizations correctly if necessary. The whole thing looks like this:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dns-challenge-missing-role
rules:
- apiGroups: ["acme.<NAME>"]
  resources: ["godaddy"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dns-challenge-missing-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: dns-challenge-missing-role
subjects:
- kind: ServiceAccount
  name: cert-manager
  namespace: cert-manager

Now I get the following error and can't get any further:

Error presenting challenge: the server could not find the requested resource (post godaddy.acme.<NAME>) 

Maybe someone here has an idea what i have done wrong, i am grateful for any tips :)

Update go client to v0.26.x

As per the removal list, v1beta1 FlowSchema and PriorityLevelConfiguration resources are removed.

These must be replaced with v1beta3, with support beginning at k8s v.1.26

TXT record created with malformed name when using subdomain under a DNS zone

I've been using the GoDaddy webhook with cert-manager on an on-prem cluster and I've encountered a situation that I'm hoping to get some clarification on.

We're running an internal DNS server with a specified DNS zone (zone.mycompany.org)

When I request a certificate for a sub-subdomain (e.g., app.zone.mycompany.org), the GoDaddy webhook seems to attempt to create the TXT record under zone.mycompany.org (as expected), but GoDaddy ends up creating the record under mycompany.org instead.

The PUT request made by the webhook:

PUT https://api.godaddy.com/v1/domains/zone.mycompany.org/records/TXT/_acme-challenge.app

results in the record being accessible at _acme-challenge.app.mycompany.org (zone is missing)

dig -t txt _acme-challenge.app.mycompany.org +short
"c-JuZ0H6dcsr1oVTk0INFciyviEi42Fnvn_mTxf5ErF"

and not at _acme-challenge.app.zone.mycompany.org

dig -t txt _acme-challenge.app.zone.mycompany.org +short

as I would expect.

I can work around this by telling cert-manager to use only public DNS servers:

dns01RecursiveNameservers: "1.1.1.1:53,1.0.0.1:53"
dns01RecursiveNameserversOnly: true

Which results in the PUT request

PUT https://api.godaddy.com/v1/domains/mycompany.org/records/TXT/_acme-challenge.app.zone

and creates the TXT record at _acme-challenge.app.zone.mycompany.org as required.

However, I'm wondering if this implies there's a limitation or a specific configuration requirement when using DNS zones with the GoDaddy webhook? Or is this likely to be an issue with how we've configured the internal DNS server?

Thanks for your time and assistance!

Additional information

Here's my config

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-staging-account-key
    solvers:
    - selector:
        dnsNames:
        - app.zone.mycompany.org
      dns01:
        webhook:
          config:
            apiKeySecretRef:
              name: godaddy-api-key
              key: token
            production: true
            ttl: 1800
          groupName: acme.mycompany.com
          solverName: godaddy
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ingress-cert
spec:
  secretName: ingress-cert-secret
  commonName: app.zone.mycompany.org
  dnsNames:
    - app.zone.mycompany.org
  duration: 2160h
  renewBefore: 360h
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

Failed to make webhook authorizer request

We are running on OCP 4.9. We did not have this problem when running on OCP 4.6 but I'm not sure if it's the cause.
When the pod is started by the deployment I get this error in the logs:
I0120 23:38:25.792011 1 secure_serving.go:123] Serving securely on [::]:443 E0120 23:38:26.212137 1 webhook.go:196] Failed to make webhook authorizer request: the server could not find the requested resource E0120 23:38:26.212299 1 errors.go:77] the server could not find the requested resource

If I start the pod in debug and call the webhook entrypoint, the log is different and it works
/ # �[6n/ # �[Jwebhook I0120 23:44:12.820241 7 serving.go:312] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key) I0120 23:44:13.220626 7 secure_serving.go:123] Serving securely on [::]:443

Would there be a reason why the self-served certificate generation does not happen when the pod is started by the deployment?

Observed a panic: runtime error: index out of range [1] with length 1

Using: godaddy-webhook 0.3.0 and jetstack/cert-manager:1.13.2

When I use the ClusterIssuer defined in README.md , changing *.example.com for *.mozai.com and groupName: acme.mycompany.com for groupName: acme.mozai.com, cert-manager complains:

"cert-manager/orders: Failed to determine the list of Challenge resources needed for the Order" err="no configured challenge solvers can be used for this challenge" resource_name="grafana-tls-1-3645741348" resource_namespace="monitoring" resource_kind="Order" resource_version="v1"

Thinking the selector block in the ClusterIssuer's only solver might be what's not matching, I get a constant stream of golang panic stacktraces, starting with this error:

runtime.go:77] Observed a panic: runtime error: index out of range [1] with length 1
goroutine 2548 [running]:
k8s.io/apiserver/pkg/endpoints/handlers/finisher.finishRequest.func1.1()
/go/pkg/mod/k8s.io/[email protected]/pkg/endpoints/handlers/finisher/finisher.go:105 +0xa5

What is causing "no solvers can be used for this challenge? Surely selector: { dnsNames: ['*.mozai.com'] } does match grafana.mozai.com so is there somewhere else I should look? and should the software be crashing that hard and that frequently if the selector is absent?

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-godaddy-prod
spec:
  acme:
    email: hostmaster.mozai.com  # dont post email addresses to webpages
    privateKeySecretRef:
      name: letsencrypt-godaddy-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        webhook:
          config:
            apiKeySecretRef:
              name: godaddy-api-key
              key: token
            production: true
            ttl: 600
          groupName: acme.mozai.com
          solverName: godaddy
      selector: {dnsNames: ['*.mozai.com']}

Documentation Godaddy API and Secret clarification

Hi team! Thank you for the webhook you created.

I have a question/suggestion to project documentation.

Problem

The explanation for Kubernetes Secret containing Godaddy credentials tells to concatenate API and Secret and place the value into token field. So I decided that it's an environment API endpoint that webhook application should use to fetch the records, either https://api.godaddy.com/ or https://api.ote-godaddy.com/.
But after concatenation (result value in token field: https://api.godaddy.com/:someapisecret) I was getting 401 from Godaddy.

README.md (main branch)

...
52 | In order to communicate with Godaddy DNS provider, we will create a Kubernetes Secret
53 | to store the Godaddy `API` and `GoDaddy Secret`. 
...

Resolved Solution

After replacing API endpoint with API Key (result value in token field: someapikey:someapisecret) all is working as expected.

Question

1. Is it actually the issue or such convention is used for Godaddy's credentials?
2. Is the explanation in note mentioned in Problem section is planned or is it an artefact from previous versions?
3. Would it be appropriate to clarify the variables' description used in Kubernetes Secret to match Godaddy's naming convention?

Suggestion

If you consider the changes relevant I could make a PR if required. Writing here some thoughts for changes:

README.md (main branch source)

...
52 | In order to communicate with Godaddy DNS provider, we will create a Kubernetes Secret
53 | to store the Godaddy API's `Key` and `Secret` from **production** or **OTE**.
...
68 | token: <GODADDY_API_KEY:GODADDY_API_SECRET>
...

Unable to create wildcard certificate

I am using cert-manager with my AKS cluster to generate Lets Encrypt certificates for my database using this webhook. Facing issue with certificate generation with error: secret not found in secret

Steps followed following the link: https://cert-manager.io/docs/configuration/acme/dns01/

1. Installed cert-manager using command: helm install cert-manager jetstack/cert-manager --version v1.9.1 --set installCRDs=true -n cert-manager –debug
2. Installed godaddy-webhook using the github repo: https://github.com/snowdrop/godaddy-webhook
   Command used: helm upgrade -i godaddy-webhook godaddy-webhook/godaddy-webhook --set groupName=acme.mydomain.com --set image.tag=v1.24.6 --set image.pullPolicy=Always --set pod.securePort=8443 --namespace cert-manager –debug
3. Created secret containing godaddy api key and secret. Deployed it in namespace : cert-manager.

apiVersion: v1
kind: Secret
metadata:
  name: godaddy-api-key
type: Opaque
stringData:
   token: <key>:<value>

4. Created a clusterIssuer apiVersion: cert-manager.io/v1

kind: ClusterIssuer                             
metadata:                               
  name: cmmx-cluster-issuer  
spec:                            
  acme:                                 
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <email>
    privateKeySecretRef:                                                                   
      name: clusterissuer-test-key
    solvers:
    - selector:
        dnsZones:
          - "mydomain.com"
          - "*.mydomain.com"
      dns01:
        webhook:
          config:
            apiKeySecretRef:
              name: godaddy-api-key
              key: token
            ttl: 900
          groupName: acme.mydomain.com
          solverName: godaddy

Deployment is successful.
5. Created a certificate
apiVersion: cert-manager.io/v1

kind: Certificate
metadata:
  name: couchbasecertificate
spec:
  dnsNames:
    - "cmmx.mydomain.com"
  secretName: couchbase-server-tls
  commonName: "cmmx.mydomain.com"
  issuerRef:
    name: cmmx-cluster-issuer
    kind: ClusterIssuer

Issuing certificate as Secret does not exist”
Also attached cert-manager pod logs for more details.
cert-manager/challenges/Present "msg"="presenting DNS01 challenge for domain" "dnsName"="cmmx.mydomain.com" "domain"="cmmx.mydomain.com" "resource_kind"="Challenge" "resource_name"="couchbasecertificate-th2jp-71168170-2435339236" "resource_namespace"="cert-manager" "resource_version"="v1" "type"="DNS-01" 1 controller.go:166] cert-manager/challenges "msg"="re-queuing item due to error processing" "error"="secret not found in secret \"godaddy-api-key/cert-manager\"" "key"="cert-manager/couchbasecertificate-th2jp-71168170-2435339236"

YAML Error on rbac.yaml caused by wrong indentation

godaddy-webhook/deploy/helm/templates/rbac.yaml

Line 115 in 6bc57df

{{ include "godaddy-webhook.labels" . | indent 4 }}

The line is indented too much (2 spaces plus 4 indentation = 6, needs 4).
__{{ include "godaddy-webhook.labels" . | indent 4 }}

Same with this line:

godaddy-webhook/deploy/helm/templates/rbac.yaml

Line 131 in 6bc57df

{{ include "godaddy-webhook.labels" . | indent 4 }}

Please delete the leading two spaces to fix it.

Misleading cluster issuer example

The example clusterIssuer has a selector that's only valid for issuing a wildcard certificate.

I propose changing the example from:

selector:
  dnsNames:
   - "*.example.com"

to:

selector:
  dnsZones:
   - "example.com"

FAIL: TestRunsSuite/Conformance/Extended/DeletingOneRecordRetainsOther

Issue

Last step of the main_test.go fails due to I suspect a finalizer issue using locally the kube api server.

I0125 11:38:46.350034   95340 round_trippers.go:435] curl -v -XGET  -H "User-Agent: godaddy-webhook.test/v0.0.0 (darwin/amd64) kubernetes/$Format" -H "Accept: application/json, */*" 'https://127.0.0.1:62284/api/v1/namespaces/extended-supports-multiple-same-domain/secrets/godaddy-credentials'
I0125 11:38:46.351535   95340 round_trippers.go:454] GET https://127.0.0.1:62284/api/v1/namespaces/extended-supports-multiple-same-domain/secrets/godaddy-credentials 200 OK in 1 milliseconds
I0125 11:38:46.351549   95340 round_trippers.go:460] Response Headers:
I0125 11:38:46.351554   95340 round_trippers.go:463]     X-Kubernetes-Pf-Flowschema-Uid: a9ac9ee9-1e97-457e-be95-27ac0173816a
I0125 11:38:46.351558   95340 round_trippers.go:463]     X-Kubernetes-Pf-Prioritylevel-Uid: 500aaf84-6569-4031-8c89-4f787a129f13
I0125 11:38:46.351562   95340 round_trippers.go:463]     Content-Length: 1005
I0125 11:38:46.351568   95340 round_trippers.go:463]     Date: Tue, 25 Jan 2022 10:38:46 GMT
I0125 11:38:46.351572   95340 round_trippers.go:463]     Audit-Id: 49dac0fc-b97e-4265-8130-2d03c882c913
I0125 11:38:46.351575   95340 round_trippers.go:463]     Cache-Control: no-cache, private
I0125 11:38:46.351579   95340 round_trippers.go:463]     Content-Type: application/json
I0125 11:38:46.351595   95340 request.go:1181] Response Body: {"kind":"Secret","apiVersion":"v1","metadata":{"name":"godaddy-credentials","namespace":"extended-supports-multiple-same-domain","uid":"44d8dc3c-5a78-4d4f-8f9f-e28219d033dc","resourceVersion":"195","creationTimestamp":"2022-01-25T10:36:44Z","annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{},\"name\":\"godaddy-credentials\",\"namespace\":\"extended-supports-multiple-same-domain\"},\"stringData\":{\"token\":\"dLDD4PTjgyQb_jKqVef5UCxHpvBczGtDHq:jL44TPNVS7RRMPQmGgTps\"},\"type\":\"Opaque\"}\n"},"managedFields":[{"manager":"kubectl-client-side-apply","operation":"Update","apiVersion":"v1","time":"2022-01-25T10:36:44Z","fieldsType":"FieldsV1","fieldsV1":{"f:data":{".":{},"f:token":{}},"f:metadata":{"f:annotations":{".":{},"f:kubectl.kubernetes.io/last-applied-configuration":{}}},"f:type":{}}}]},"data":{"token":"ZExERDRQVGpneVFiX2pLcVZlZjVVQ3hIcHZCY3pHdERIcTpqTDQ0VFBOVlM3UlJNUFFtR2dUcHM="},"type":"Opaque"}
I0125 11:38:46.351667   95340 wait.go:329] Returning cached zone record "snowdrop.me." for fqdn "snowdrop.me."
I0125 11:38:46.675211   95340 request.go:1181] Request Body: {"kind":"DeleteOptions","apiVersion":"v1"}
I0125 11:38:46.675252   95340 round_trippers.go:435] curl -v -XDELETE  -H "Accept: application/json, */*" -H "Content-Type: application/json" -H "User-Agent: godaddy-webhook.test/v0.0.0 (darwin/amd64) kubernetes/$Format" 'https://127.0.0.1:62284/api/v1/namespaces/extended-supports-multiple-same-domain'
I0125 11:38:46.680062   95340 round_trippers.go:454] DELETE https://127.0.0.1:62284/api/v1/namespaces/extended-supports-multiple-same-domain 200 OK in 4 milliseconds
I0125 11:38:46.680087   95340 round_trippers.go:460] Response Headers:
I0125 11:38:46.680092   95340 round_trippers.go:463]     X-Kubernetes-Pf-Flowschema-Uid: a9ac9ee9-1e97-457e-be95-27ac0173816a
I0125 11:38:46.680096   95340 round_trippers.go:463]     X-Kubernetes-Pf-Prioritylevel-Uid: 500aaf84-6569-4031-8c89-4f787a129f13
I0125 11:38:46.680099   95340 round_trippers.go:463]     Content-Length: 636
I0125 11:38:46.680102   95340 round_trippers.go:463]     Date: Tue, 25 Jan 2022 10:38:46 GMT
I0125 11:38:46.680105   95340 round_trippers.go:463]     Audit-Id: ce4fe09a-9b0a-45a1-a988-d467e5b8b3c7
I0125 11:38:46.680109   95340 round_trippers.go:463]     Cache-Control: no-cache, private
I0125 11:38:46.680112   95340 round_trippers.go:463]     Content-Type: application/json
I0125 11:38:46.680125   95340 request.go:1181] Response Body: {"kind":"Namespace","apiVersion":"v1","metadata":{"name":"extended-supports-multiple-same-domain","uid":"3d5c7afb-911a-4a12-977d-253c9b0ac9e4","resourceVersion":"208","creationTimestamp":"2022-01-25T10:36:43Z","deletionTimestamp":"2022-01-25T10:38:46Z","labels":{"kubernetes.io/metadata.name":"extended-supports-multiple-same-domain"},"managedFields":[{"manager":"godaddy-webhook.test","operation":"Update","apiVersion":"v1","time":"2022-01-25T10:36:43Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:labels":{".":{},"f:kubernetes.io/metadata.name":{}}}}}]},"spec":{"finalizers":["kubernetes"]},"status":{"phase":"Terminating"}}
--- FAIL: TestRunsSuite (170.27s)
    --- FAIL: TestRunsSuite/Conformance (162.21s)
        --- PASS: TestRunsSuite/Conformance/Basic (25.34s)
            --- PASS: TestRunsSuite/Conformance/Basic/PresentRecord (25.34s)
        --- FAIL: TestRunsSuite/Conformance/Extended (123.66s)
            --- FAIL: TestRunsSuite/Conformance/Extended/DeletingOneRecordRetainsOthers (123.66s)
FAIL
FAIL    github.com/snowdrop/godaddy-webhook     170.770s
FAIL

Unable to check the TXT record: ### Unexpected HTTP status: 403

I got error while configuring cert-manager with godaddy webhook, Here are the logs:

1. Certificate

Name:         letsencrypt-prod
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  cert-manager.io/v1
Kind:         Certificate

Events:
  Type    Reason     Age   From                                       Message
  ----    ------     ----  ----                                       -------
  Normal  Issuing    11m   cert-manager-certificates-trigger          Issuing certificate as Secret does not exist
  Normal  Generated  11m   cert-manager-certificates-key-manager      Stored new private key in temporary Secret resource "letsencrypt-prod-vk6fg"
  Normal  Requested  11m   cert-manager-certificates-request-manager  Created new CertificateRequest resource "letsencrypt-prod-1

2. CertificateRequest

Name:         letsencrypt-prod-1
Namespace:    default
Labels:       <none>
Annotations:  cert-manager.io/certificate-name: letsencrypt-prod
              cert-manager.io/certificate-revision: 1
              cert-manager.io/private-key-secret-name: letsencrypt-prod-vk6fg
API Version:  cert-manager.io/v1
Kind:         CertificateRequest

Events:
  Type    Reason              Age   From                                                Message
  ----    ------              ----  ----                                                -------
  Normal  WaitingForApproval  12m   cert-manager-certificaterequests-issuer-vault       Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  12m   cert-manager-certificaterequests-issuer-selfsigned  Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  12m   cert-manager-certificaterequests-issuer-acme        Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  12m   cert-manager-certificaterequests-issuer-ca          Not signing CertificateRequest until it is Approved
  Normal  WaitingForApproval  12m   cert-manager-certificaterequests-issuer-venafi      Not signing CertificateRequest until it is Approved
  Normal  cert-manager.io     12m   cert-manager-certificaterequests-approver           Certificate request has been approved by cert-manager.io
  Normal  OrderCreated        12m   cert-manager-certificaterequests-issuer-acme        Created Order resource default/letsencrypt-prod-1-112517667
  Normal  OrderPending        12m   cert-manager-certificaterequests-issuer-acme        Waiting on certificate issuance from order default/letsencrypt-prod-1-112517667: ""

3. Order

Name:         letsencrypt-prod-1-112517667
Namespace:    default
Labels:       <none>
Annotations:  cert-manager.io/certificate-name: letsencrypt-prod
              cert-manager.io/certificate-revision: 1
              cert-manager.io/private-key-secret-name: letsencrypt-prod-vk6fg
API Version:  acme.cert-manager.io/v1
Kind:         Order

Events:
  Type    Reason   Age   From                 Message
  ----    ------   ----  ----                 -------
  Normal  Created  13m   cert-manager-orders  Created Challenge resource "letsencrypt-prod-1-112517667-2756939281" for domain "testps.adeiz.com"

4. Challenge

Name:         letsencrypt-prod-1-112517667-2756939281
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  acme.cert-manager.io/v1
Kind:         Challenge

Events:
  Type     Reason        Age                  From                     Message
  ----     ------        ----                 ----                     -------
  Normal   Started       14m                  cert-manager-challenges  Challenge scheduled for processing
  Warning  PresentError  3m49s (x8 over 14m)  cert-manager-challenges  Error presenting challenge: the server is currently unable to handle the request (post godaddy.acme.mycompany.com)

5. cert-manager

I0109 20:13:50.0830181 dns.go:88] "cert-manager/challenges/Present: presenting DNS01 challenge for domain" resource_name="letsencrypt-prod-1-112517667-2756939281" resource_namespace="default" resource_kind="Challenge" resource_version="v1" dnsName="testps.adeiz.com" type="DNS-01" resource_name="letsencrypt-prod-1-112517667-2756939281" resource_namespace="default" resource_kind="Challenge" resource_version="v1" domain="testps.adeiz.com"

E0109 20:13:50.0916421 controller.go:167] "cert-manager/challenges: re-queuing item due to error processing" err="the server is currently unable to handle the request (post godaddy.acme.mycompany.com)" key="default/letsencrypt-prod-1-112517667-2756939281"

6. godaddy webhook

E0109 20:19:10.1000231 runtime.go:77] Observed a panic: runtime error: index out of range [1] with length 1

7. Api-server

I0109 20:21:49.651391       1 controller.go:129] OpenAPI AggregationController: action for item v1alpha1.acme.mycompany.com: Rate Limited Requeue.
E0109 20:23:49.655186       1 controller.go:116] loading OpenAPI spec for "v1alpha1.acme.mycompany.com" failed with: OpenAPI spec does not exist

Here are the config files:

1. Godaddy Api secret

apiVersion: v1
kind: Secret
metadata:
  name: godaddy-api-key
  namespace: default
type: Opaque
stringData:
  token: <api_key:secret> # echo -n "<api_key:secret>" | base64

2. Issuer

apiVersion: cert-manager.io/v1
kind:  Issuer #ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: default
  labels:
     app: adeiz-ca-cert
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <email>
    privateKeySecretRef:
      name:  adeiz-ca
    solvers:
    - selector:
        dnsNames:
        - '*.testps.adeiz.com'
      dns01:
        webhook:
          config:
            apiKeySecretRef:
              name: godaddy-api-key
              key: token
            production: true
            ttl: 600
          groupName: acme.mycompany.com
          solverName: godaddy 

3. Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: adeiz-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    #cert-manager.io/cluster-issuer: "letsencrypt-prod"
    #cert-manager.io/issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - '*.testps.adeiz.com'
    secretName: adeiz-ca
  rules:
  - host: test.testps.adeiz.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-hello-world
            port:
              number: 80

4. Certificate

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: adeiz-ca
  labels:
    app: adeiz-ca-cert
  namespace: default
spec:
  renewBefore: 2136h
  duration: 2190h
  privateKey:
    size: 2048
    algorithm: RSA
  issuerRef:
    kind: Issuer
    name: letsencrypt-prod
  secretName:  adeiz-ca 
  dnsNames:
    - '*.testps.adeiz.com'

Cluster configured with kubeadm in a baremetal

I am also not sure if i should change the groupName cause changing it gave me errors, or should i edit the clusterrole and clustrerrolebinding before deploying godaddywebhook ?