Let’s Encrypt Rate Limits: Wildcard Certificates Unleashed!

Recently, I spent some time trying to issue Wildcard SSL certificates to my domain using Cert Manager and Let’s Encrypt.

Introduction

In today’s digital landscape, securing your web applications with HTTPS is crucial. Let’s Encrypt has revolutionized the way we obtain SSL/TLS certificates by providing them for free. However, managing these certificates, especially for complex environments like Kubernetes, can be challenging. This is where Cert Manager comes in handy. In this blog post, we will explore how to generate wildcard certificates using Cert Manager and Let’s Encrypt on Kubernetes, while also discussing Let’s Encrypt’s rate limits and how to navigate them effectively. Additionally, we will introduce Reflector, a Kubernetes addon that simplifies secret & config management across namespaces.

Understanding Let’s Encrypt Rate Limits

Let’s Encrypt enforces rate limits to ensure fair usage of their service. These limits are essential to prevent abuse but can pose challenges if not understood properly. Here are some key rate limits to be aware of:

1. Certificates per Registered Domain (50 per week): You can only issue 50 certificates per registered domain per week. This includes renewals.
2. New Orders (300 per 3 hours): You can create a maximum of 300 New Orders per account per 3 hours.
3. Names per Certificate(100): You can combine multiple hostnames into a single certificate, up to a limit of 100 Names per Certificate
4. Duplicate Certificates (5 per week): You can issue a maximum of 5 duplicate certificates per week.
5. Failed Validations (5 per hour): There is a limit of 5 failures per account, per hostname, per hour.
6. Account Creation (10 per 3 hours): You can create a maximum of 10 Accounts per IP Address per 3 hours
7. Pending Authorizations: You can have a maximum of 300 Pending Authorizations on your account

Understanding these limits is crucial for planning and implementing your SSL strategy effectively.

Why Wildcard Certificates?

Wildcard certificates offer a significant advantage by allowing you to secure an unlimited number of subdomains with a single certificate. For instance, a wildcard certificate for *.example.com can secure www.example.com, blog.example.com, shop.example.com, and any other subdomain. This simplifies certificate management, especially in dynamic environments like Kubernetes.

To issue wildcard certificates, you must use the ACME v2 endpoint and validate via DNS-01 challenge. Let’s go through the steps to set up wildcard certificates:

Setting Up Cert Manager on Kubernetes

Cert Manager is a powerful tool that automates the issuance and renewal of TLS certificates in Kubernetes

Step 1: Install Cert Manager

First, install Cert Manager using Helm:

create a values.yaml file

installCRDs: true

extraArgs:
  - --enable-certificate-owner-ref=true
  - --dns01-recursive-nameservers-only
  - --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53

featureGates: "AdditionalCertificateOutputFormats=true"

and then run the following commands

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm upgrade --install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --values=values.yaml

Step 2: Configure the ClusterIssuer

Configure a ClusterIssuer for Let’s Encrypt using the DNS-01 challenge. Here’s an example configuration:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns-cluster-issuer
spec:
  acme:
    email: developer@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-dns-cluster-issuer-private-key
    solvers:
    - selector:
        dnsZones:
          - "example.com"
      dns01:
        route53:
          region: ap-south-1
          hostedZoneID: Q1W2E3R4T5Y6U7I8
          accessKeyIDSecretRef:
            name: aws-credentials-secrets
            key: access-key-id
          secretAccessKeySecretRef:
            name: aws-credentials-secrets
            key: secret-access-key

Before going to next step let’s me first, introduce you to Reflector

Introducing Reflector for Resource Management

Reflector is a Kubernetes addon designed to monitor changes to resources (secrets and configmaps) and reflect changes to mirror resources in the same or other namespaces. This can be incredibly useful when dealing with wildcard certificates, ensuring that all necessary namespaces have access to the required secrets.

Step 3: Install Reflector

You can install Reflector using Helm as follows:

helm repo add emberstack https://emberstack.github.io/helm-charts
helm repo update
helm upgrade --install reflector emberstack/reflector

To mirror the secrets across namespace annotate the source secret

• Add reflector.v1.k8s.emberstack.com/reflection-allowed: "true" to the resource annotations to permit reflection to mirrors.

Automatic mirror creation:

Reflector can create mirrors with the same name in other namespaces automatically. The following annotations control if and how the mirrors are created:

• Add reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true" to the resource annotations to automatically create mirrors in other namespaces. Note: Requires reflector.v1.k8s.emberstack.com/reflection-allowed to be true since mirrors need to able to reflect the source.

If you want to permit reflection in specific namespaces you can annotate the source as following

• Add reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "<list>" to the resource annotations to permit reflection from only the list of comma separated namespaces or regular expressions. Note: If this annotation is omitted or is empty, all namespaces are allowed.

Step 4: Create a Certificate Resource

Now lets create a cretificate and annotate with the reflector annotation to reflect across namespaces

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-certificate
spec:
  secretName: wildcard-certificate-secret
  secretTemplate:
    annotations:
      reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
      reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true"
  issuerRef:
    name: letsencrypt-dns-cluster-issuer
    kind: ClusterIssuer
  commonName: "*.example.com"
  dnsNames:
    - "example.com"
    - "*.example.com"

By annotating the secret with reflector.v1.k8s.emberstack.com/reflection-allowed: "true" andreflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true" , Reflector will ensure that the wildcard certificate secret is available across these namespaces. With this, you can now use the certificate secrets in ingress to secure your applications with HTTPS

Managing Let’s Encrypt Rate Limits

To effectively manage Let’s Encrypt rate limits, consider the following strategies:

• Use Staging Environment for Testing: Before deploying to production, test your configuration with Let’s Encrypt’s staging environment to avoid hitting rate limits.
• Monitor Certificate Expiry: Keep an eye on certificate expiry dates and ensure timely renewals to avoid downtime.
• Optimize Certificate Requests: Combine multiple subdomains under a single wildcard certificate to reduce the number of certificate requests.
• Use Multiple Issuers: Distribute your certificate requests across multiple issuers if your rate limits are being exhausted.

Conclusion

Generating wildcard certificates using Cert Manager and Let’s Encrypt on Kubernetes simplifies certificate management and enhances security. Reflector further streamlines this process by ensuring secrets are mirrored across necessary namespaces. By understanding and navigating Let’s Encrypt’s rate limits, you can ensure a smooth and reliable implementation. Start leveraging the power of wildcard certificates and take your Kubernetes deployments to the next level!

By following the steps outlined in this blog post, you can confidently set up and manage wildcard certificates in your Kubernetes environment. Happy securing!

Feel free to reach out in the comments if you have any questions or need further assistance.