Emtpy “ca.crt” file from cert-manager

Question

I use cert-manager to generate TLS certificates for my application on Kubernetes with Let's Encrypt.

It is running and I can see "ca.crt", "tls.crt" and "tsl.key" inside the container of my application (in /etc/letsencrypt/ ).

But "ca.crt" is empty, and the application complains about it ( Error: Unable to load CA certificates. Check cafile "/etc/letsencrypt/ca.crt" ). The two other files look like normal certificates.

What does that mean?

Answer 1

With cert-manager you have to use the nginx-ingress controller which will work as expose point.

ingress nginx controller will create one load balancer and you can setup your application tls certificate there.

There is nothing regarding certificate inside the pod of cert-manager.

so setup nginx ingress with cert-manager that will help to manage the tls certificate. that certificate will be stored in kubernetes secret.

Please follow this guide for more details:

https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes

Answer 2

According to the documentation, cafile is for something else (trusted root certificates), and it would probably be more correct to use capath /etc/ssl/certs on most systems.

You can follow this guide if you have Windows Operating System: tls . Article is about how to enable Mosquitto and clients to use the TLS protocol.

Establishing a secure TLS connection to the Mosquitto broker requires key and certificate files. Creating all these files with the correct settings is not the easiest thing, but is rewarded with a secure way to communicate with the MQTT broker.

If you want to use TLS certificates you've generated using the Let's Encrypt service. You need to be aware that current versions of mosquitto never update listener settings when running, so when you regenerate the server certificates you will need to completely restart the broker.

If you use DigitalOcean Kubernetes try to follow this instruction: ca-ninx , you can use Cert-Manager and ingress nginx controller, they will work like certbot.

Another solution is to create the certificate locally on your machine and then upload it to kubernetes secret and use secret on ingress.

Answer 3

I noticed this:

$ kubectl describe certificate iot-mysmartliving -n mqtt
...
Status:
  Conditions:
    ...
    Message:  Certificate issuance in progress. Temporary certificate issued.

and a related line in the docs:

https://docs.cert-manager.io/en/latest/tasks/issuing-certificates/index.html?highlight=gce#temporary-certificates-whilst-issuing

They explain that the two existing certificates are generated for some compatibility, but they are not valid until the issuer has done its work.

So that suggests that the issuer is not properly set up.

---

Edit : yes it was. The DNS challenge was failing, the debug line that helped was

kubectl describe challenge --all-namespaces=true

More generally,

kubectl describe clusterissuer,certificate,order,challenge --all-namespaces=true