Blocking old cert-manager versions - what action is required?

We received the email that is referenced in this post - Blocking old cert-manager versions

I have looked on our servers and we have certbot 0.28.0 which is the highest version for Debian 9. It is not clear from the email if I need to do anything in this case as it only mentions the cert-manager version. I’m assuming that certbot uses certbot-manager for something? How do I know what version of cert-manager is being used? Do I need to update certbot to use an updated version of cert-manager or will it use the latest version. Or do I need to update cert-manager some other way? As you can see we have been getting in a muddle about what action we need to take (if any).

My domain is:

I ran this command: certbot --version

It produced this output: certbot 0.28.0

My web server is (include version): NGINX

The operating system my web server runs on is (include version): Debian 9

My hosting provider, if applicable, is: Google Cloud (Compute Engine)

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): Yes, Google Cloud

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot version is 0.28.0

That is an incorrect assumption.

Probably, your ACME account has used cert-manager (not certbot-manager, that doesn't exist) in the past or perhaps even the present.

If you are absolutely sure you are only using certbot, there is nothing to worry about. However, it seems Let's Encrypt has the opinion you have used cert-manager with the ACME-account corresponding with the e-mail address on which you received the warning, so you should double check if you're really not using cert-manager in any way.

1 Like

Jetstack’s cert-manager is a tool used for managing certificates in a Kubernetes cluster. Do you run a Kubernetes cluster anywhere, or have you in the past? I believe the email includes the affected IP addresses - you should check the machine running that IP address and see if it’s running Kubernetes with cert-manager.


Sorry yes I meant ‘cert-manager’ not ‘certbot-manager’. What do you mean by ACME account?

The email does contain an IP and it’s not related to any of my servers. The servers are running Docker images, but not Kubernetes as far as I know. Are they different things?

Kubernetes is a system for running Docker containers. It’s possible that you or someone in your company might be running cert-manager in Docker containers without Kubernetes, though that would be unusual.

Is it possible that the IP address used to be associated with one of your servers, and you disabled that server or changed IP addresses?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.