Generate wildcard certificate on Kubernetes cluster with DigitalOcean for my Nginx-Ingress

Question

I followed this DigitalOcean guide https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes, and I came across something quite strange. When in the hostnames I set a wildcard, then letsencrypt fails in issuing a new certificate. While when I only set defined sub-domains, then it works perfectly.

This is my "working" configuration for the domain and its api (and this one works perfectly):

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
  tls:
  - hosts:
    - example.com
    - api.example.com
    secretName: my-tls
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: example-frontend
          servicePort: 80
  - host: api.example.com
    http:
      paths:
      - backend:
          serviceName: example-api
          servicePort: 80

And this is, instead, the wildcard certificate I'm trying to issue, but that fails to do leaving the message "Issuing".

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
  tls:
  - hosts:
    - example.com
    - *.example.com
    secretName: my-tls
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: example-frontend
          servicePort: 80
  - host: api.example.com
    http:
      paths:
      - backend:
          serviceName: example-api
          servicePort: 80
      

The only difference is the second line of the hosts. Is there a trivial well known solution I am not aware of? I am new to Kubernetes, but not to DevOps.

Answer 1

Generating wildcard certificate with cert-manager (letsencrypt) requires the usage of DNS-01 challenge instead of HTTP-01 used in the link from the question:

Does Let’s Encrypt issue wildcard certificates?

Yes. Wildcard issuance must be done via ACMEv2 using the DNS-01 challenge. See this post for more technical information.

There is a documentation about generating the wildcard certificate with cert-manager:

• Cert-manager.io: Docs: Configuration: ACME: DNS-01

---

From the perspective of DigialOcean, there is a guide specifically targeted at it:

This provider uses a Kubernetes Secret resource to work. In the following example, the Secret will have to be named digitalocean-dns and have a sub-key access-token with the token in it. For example:

apiVersion: v1
kind: Secret
metadata:
  name: digitalocean-dns
  namespace: cert-manager
data:
  # insert your DO access token here
  access-token: "base64 encoded access-token here"

The access token must have write access.

To create a Personal Access Token, see DigitalOcean documentation.

Handy direct link: https://cloud.digitalocean.com/account/api/tokens/new

To encode your access token into base64, you can use the following

echo -n 'your-access-token' | base64 -w 0

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: example-issuer
spec:
  acme:
    ...
    solvers:
    - dns01:
        digitalocean:
          tokenSecretRef:
            name: digitalocean-dns
            key: access-token

-- Cert-manager.io: Docs: Configuration: ACME: DNS-01: Digitalocean

---

I'd reckon this additional resources could also help:

• Stackoverflow.com: Questions: Wilcard SSL certificate with subdomain redirect in Kubernetes
• Itnext.io: Using wildcard certificates with cert-manager in Kubernetes

Answer 2

Wildcard cert require DNS-01 method

Note : You might require to first add the CAA record in your DNS.

CAA record can get added into DNS zone

example :

            Type       Value

devops.in   CAA       0 issuewild "letsencrypt.org"

get details from : https://sslmate.com/caa/

First, you have to create the secret for storing the access key using the command

kubectl create secret generic route53-secret --from-literal=secret-access-key="skjdflk4598sf/dkfj490jdfg/dlfjk59lkj"

Here sharing the example issuer.yaml

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: test123@gmail.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - selector:
        dnsZones:
          - "devops.in"
      dns01:
        route53:
          region: us-east-1
          hostedZoneID: Z2152140EXAMPLE
          accessKeyID: AKIA5A5D7EXAMPLE
          secretAccessKeySecretRef:
            name: route53-secret
            key: secret-access-key
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: le-crt
spec:
  secretName: tls-secret
  issuerRef: 
    kind: Issuer
    name: letsencrypt-prod
  commonName: "*.devops.in"
  dnsNames:
    - "*.devops.in" 

Also, make sure your user has necessary permission to manage the Route53

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