8

I am using cert-manager-v0.10.0 installed from its helm chart

I am using kong like ingress controller to manage the ingress operations.

So I have created a ClusterIssuer resource in order it could be contacted from an Ingress resource via kong-ingress controller.

The ClusterIssuer is this:

   apiVersion: certmanager.k8s.io/v1alpha1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-prod
   spec:
     acme:
       # The ACME server URL
       server: https://acme-v02.api.letsencrypt.org/directory
       # Email address used for ACME registration
       email: username@mydomain.org
       # Name of a secret used to store the ACME account private key
       privateKeySecretRef:
         name: letsencrypt-prod
       # Enable the HTTP-01 challenge provider
       solvers:
       - http01:
           ingress:
             class: kong

The ingress resource that I am using is this.

You can see here, that I am pointing it to the ClusterIssuer created previously and also I am pointing it to kong as an ingress controller, according to the kubernetes.io/ingress.class: "kong" annotation included there:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    # add an annotation indicating the issuer to use.
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod # letsencrypt-staging
    kubernetes.io/ingress.class: "kong"
    plugins.konghq.com: swaggerapi-customer-production-basic-auth, swaggerapi-customer-production-acl
  name: production-customer-ingress-app
  # namespace: default
spec:
  rules:
  - host: appprod.mydomain.org
    http:
      paths:
      - backend:
          serviceName: customer-production-app
          servicePort: 80
        path: /comcustomerpr
  tls: # < placing a host in the TLS config will indicate a cert should be created
  - hosts:
    - appprod.mydomain.org
    secretName: letsencrypt-prod # < cert-manager will store the created certificate in this secret.

So, when I create the Ingress resource above, the secretName referenced above in my ingress is created and also a certificate resource with the same name ... that is letsencrypt-prod.

It will be the certificate resource which receive the LetsEncrypt validation successful process ...

I got TLS encryption and everything is OK here.

But now, I want to know how will be the renewal process. Because I am pretty sure at the moment this renewal certificate process it does not to happen automatically ...

I was reading something here https://docs.cert-manager.io/en/latest/reference/certificates.html?highlight=renewal#certificate-duration-and-renewal-window and this documentation says that is necessary attach to the certificate resource created (kind:Certificate) the spec.duration and spec.renewBefore attributes of this way

spec:
  secretName: example-tls
  duration: 24h
  renewBefore: 12h

If my certificate issued by LetsEncrypt has a 90 days as a default duration, how can I specify these spec.duration and spec.renewBefore attributes?

I want to get into in this concern, because my main question is I am not creating the certificate, it is created when the Ingress resource (above referenced) is executed.

How can I address the renewal process here with this approach that I am doing?

UPDATE

Do I need to create a specific kind:Certificate resource, referencing the secret that I got from LetsEncrypt?

I mean, something like this?

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: letsencrypt-prod
spec:
  secretName: letsencrypt-prod
  dnsNames:
  - mydomain.com
  acme:
    config:
    - http01:
        ingressClass: kong
      domains:
      - mydomain.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

I have the doubt here, because currently I am not getting the certificate renewal action

bgarcial
  • 2,915
  • 10
  • 56
  • 123

1 Answers1

4

since you have used the letsencrypt-prod issuer, and haven't done anything special/non-standard, the certificate renewal process will be completely automatic for you.

By default the letsencrypt certificates are valid fro 90-days, and renewed automatically every 30-days. If you don't have some strict requirements to use purchased certificates, or use some other specific Certificate Authority, this is a great option to use.

If you still have doubts then you can do the following to see for yourself. First decode the current certificates secret data and inspect the certificate contents with the openssl command. You'll be able to see the certificate expiry date, and make a note of that. Now if you subtract 59-days from that expiry date that should give you roughly the date that cert-manager will attempt to renew the certificate on. I add an extra day just to be safe we aren't too early. Then on that date repeat this process again; decoding the certificate secret, inspecting the certificate with the openssl command, and checking the certificate expiry date. You'll notice the expiry date for the certificate is different than before, hence it's was automatically renewed as we expected.

Hope this helps.

cewood
  • 1,011
  • 8
  • 11
  • 2
    The automatic renewal process is I thought, but I have doubts because I did this same process (create the certficates, using `kong`, `cert-manager-v0.7.0` and talking to letsencrypt) some months ago and when the validity there were expired, the automatic renewal process never did happen, I had to recreate the ingress process in order to kong and cert-manager talk again to letsencrypt in order to get a new certificate ... – bgarcial Sep 13 '19 at 08:32
  • I can do that you says, I think is the best option to check this behavior, but I have a doubt about how can I modify the validity period ... I mean I would need to modify the certificate ... I found how check its information, but not sure about how can I substract the specific amount of days ... – bgarcial Sep 13 '19 at 08:45
  • @bgarcial Did you solve the issue? I have the same problem – NehaM Dec 11 '20 at 14:29
  • @NehaM, nowadays, this process is entirely automatic, Let's Encrypt takes care of that. – bgarcial Dec 12 '20 at 09:25
  • 2
    I've gone through this twice before. Completely vanilla cert-manager k8s install, but at expiration, certs did not renew, which left me scrambling to force renewal. Twice before I had to tear down the whole config and re-create it. I'm about to see this happen again. – vincent Sep 23 '21 at 13:56
  • "Have you try turning it off and on again?" - it worked for me. I removed all the pods from the cert-manager namespace, and the certificates were renewed in a couple of minutes. Which is absolutely awful. But it worked. If this kind of freckery happens again, I'm gonna be off for some serious debugging. – netom Sep 30 '21 at 19:45