4 min read1 day ago

–

In Part 1 of our GitOps on Azure Series, we built a fully functional GitOps setup on Azure , deploying AKS and ArgoCD, wiring up Ingress, and setting the stage for automated SSL, all through Terraform.

But we left one big question open: Who actually issues and manages those SSL certificates?

That’s where cert-manager and ClusterIssuer step in.

The Big Picture

Imagine your cluster as a city. Ingress controllers are like security gates deciding who can enter, and cert-manager is the officer verifying everyone’s ID, the SSL certificates.

When your app needs HTTPS, cert-manager is the one that requests, validates, and renews certificates behind the scenes, ensuring your site stays secure without manual intervention.

Press enter or click to view image in full size

In this part, we will unpack how cert-manager works internally, how it talks to Let’s Encrypt (or any other CA), what the ClusterIssuer resource really does, and how it ties back to the Ingress flow we discussed earlier.

If you’ve ever wondered what really happens when you add this annotation:

cert-manager.io/cluster-issuer: letsencrypt-prod

in your Ingress annotation, this article is for you.

You can always clone the code from my Github repo to follow along: https://github.com/ateeb327/AKS-ArgoCD

What We Need for SSL Automation

In order to deploy SSL for our app, we need four things:

1. Cert-Manager Helm Chart Picture this as installing the “brains” of the operation, a set of pods that handle everything from requesting to renewing certificates.

2. ClusterIssuer Resource Think of this as the policy or configuration that tells cert-manager where and how to get the certificate. For example, from Let’s Encrypt’s production or staging environment.

3. Ingress Annotation The line cert-manager.io/cluster-issuer: letsencrypt-prod is what glues everything together. It tells cert-manager: “For this Ingress, use the *letsencrypt-prod* ClusterIssuer to fetch a certificate for the host defined here.”

4. Kubernetes Secret Like a safe deposit box, this is where cert-manager stores the final certificate and private key after issuance.

Get Muhammad Ateeb Aslam’s stories in your inbox

Join Medium for free to get updates from this writer.

Now, we know what is required, let’s start connecting the dots.

How cert-manager Works Under the Hood

Let’s zoom in.

Press enter or click to view image in full size

When you deploy an app with Ingress and annotate it with a ClusterIssuer (the aboive annotation that we saw), here’s what happens step-by-step:

1. cert-manager watches your Ingress. As soon as it sees an annotation pointing to a ClusterIssuer, it springs into action.
2. It creates a Certificate resource automatically. This internal resource represents the desired certificate e.g domain, duration, and secret name.
3. It contacts the defined ClusterIssuer. The ClusterIssuer contains all the information needed to talk to the certificate authority (CA), such as Let’s Encrypt’s API endpoint and the type of challenge (usually HTTP-01 or DNS-01).
4. Validation (The Challenge). Picture this: Let’s Encrypt asks, “Do you really own this domain?” cert-manager responds by spinning up a temporary pod (ussually a temporary ingress called solver-ingress) or modifying DNS records, proving domain ownership.
5. Certificate Issuance. Once validation passes, the CA sends back the signed certificate. cert-manager then stores it inside a Kubernetes Secret (usually named after your domain).
6. Automatic Renewal. Certificates are not forever. cert-manager quietly monitors expiration and renews them e.g typically 30 days before expiry thus ensuring zero downtime or warnings in browsers.

Understanding ClusterIssuer

A ClusterIssuer is just a Kubernetes resource, but it’s the anchor of your SSL automation strategy.

It defines which Certificate Authority (CA) to use and how to authenticate with it. Below I have included a minimal example using Let’s Encrypt production:

apiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:  name: letsencrypt-prodspec:  acme:    email: you@example.com    server: https://acme-v02.api.letsencrypt.org/directory    privateKeySecretRef:      name: letsencrypt-prod    solvers:      - http01:          ingress:            class: nginx

This tells cert-manager (using the cert-manager annotation):

“Whenever you want to get an SSL, use Let’s Encrypt’s production API, identify yourself with this private key, and solve the challenge through the NGINX Ingress controller.”

Every time you apply an Ingress with the matching annotation, cert-manager refers to this configuration to decide how to fetch the certificate.

Bringing It All Together

Like an orchestra, each component plays its part:

• The Ingress defines what domain needs SSL.
• The Annotation signals which policy (ClusterIssuer) to follow.
• The ClusterIssuer knows how to talk to the CA.
• The Cert-Manager Pods handle the actual issuance and renewal.
• The Secret safely stores the finished certificate.

Together, they automate the full certificate lifecycle and that’s all GitOps-friendly, all declarative, all hands-free.

Final Thoughts

GitOps isn’t just about deploying apps automatically; it’s about automating trust. With cert-manager and ClusterIssuer, your cluster becomes self-reliantable to prove its identity, request certificates, and renew them without any manual step.

Thanks for reading. If this sparked even a tiny thought in you, imagine what the next one might do. So clap, follow, and subscribe, and let’s keep building ideas together.