How to determine whether certbot is still active

certbot 2.9.0

Ubuntu 22.04

A couple of months ago I changed the way I obtained LE certificates to the acme challenge (haproxy allows for this or demands this method).
The latest files in /etc/letsencrypt/archive/my.domain.org/ are dated Oct 23. Since then no updates. So I can assume that certbot isn't active anymore. How can I determine whether it's really deactivated?

Do the files in /etc/letsencrypt/renewal-hooks/deploy apply only to certbot or are they active for .acme.sh also?

And with "active" and "deactivated", you actually mean "Is there a cronjob or systemd timer running"?

Certbot logs all its activity to /var/log/letsencrypt/ by default, so you should see new logs appear there periodically.

2 Likes

Thanks. I'm always a bit hesitant to post these logs since I don't know whether the contain sensitive information, keys, etc. but anyway, here is the first log of 2024-03-09_

2024-03-09 09:13:16,722:DEBUG:urllib3.connectionpool:http://localhost:None "GET /v2/connections?snap=certbot&interface=content HTTP/1.1" 200 97
2024-03-09 09:13:17,243:DEBUG:certbot._internal.main:certbot version: 2.9.0
2024-03-09 09:13:17,243:DEBUG:certbot._internal.main:Location of certbot entry point: /snap/certbot/3643/bin/certbot
2024-03-09 09:13:17,243:DEBUG:certbot._internal.main:Arguments: ['-q', '--preconfigured-renewal']
2024-03-09 09:13:17,243:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-03-09 09:13:17,254:DEBUG:certbot._internal.log:Root logging level set at 40
2024-03-09 09:13:17,255:DEBUG:certbot._internal.display.obj:Notifying user: Processing /etc/letsencrypt/renewal/mail.kukulies.org.conf
2024-03-09 09:13:17,257:DEBUG:certbot._internal.plugins.selection:Requested authenticator None and installer None
2024-03-09 09:13:17,257:DEBUG:certbot._internal.plugins.selection:Requested authenticator None and installer None
2024-03-09 09:13:17,277:DEBUG:certbot._internal.storage:Should renew, less than 30 days before certificate expiry 2024-01-21 14:22:17 UTC.
2024-03-09 09:13:17,277:INFO:certbot._internal.renewal:Certificate is due for renewal, auto-renewing...
2024-03-09 09:13:17,278:INFO:certbot._internal.renewal:Non-interactive renewal: random delay of 273.42721788892527 seconds
2024-03-09 09:17:50,789:DEBUG:certbot._internal.plugins.selection:Requested authenticator apache and installer apache
2024-03-09 09:17:50,982:DEBUG:certbot_apache._internal.configurator:Apache version is 2.4.52
2024-03-09 09:17:51,258:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * apache
Description: Apache Web Server plugin
Interfaces: Authenticator, Installer, Plugin
Entry point: EntryPoint(name='apache', value='certbot_apache._internal.entrypoint:ENTRYPOINT', group='certbot.plugins')
Initialized: <certbot_apache._internal.override_debian.DebianConfigurator object at 0x7fb745edb160>
Prep: True
2024-03-09 09:17:51,260:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * apache


...


httpd not running, trying to start
Action 'graceful' failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
                                                   

What I'm wondering about is that there is a certbot apache plugin involved. I'm not running apache.
(haproxy instead).

So it looks like Certbot is installed using snap and snap is using its systemd timer to run Certbot regularly, so that's good.

What isn't good is that it fails to get a new certificate.

Did you run Apache in the past perhaps? Because Certbot wouldn't do that on its own when renewing. The error is to be expected haproxy is already listening on port 80 and Apache, being started by the Certbot apache plugin, also tries to do that..

Note that for the hostname mail.kukulies.org currently there's nothing listening on port 80: I'm getting a "connection refused" error currently.

Also note that for the mail.kukulies.org hostname you've gotten ZeroSSL certificates for the past few months (crt.sh | mail.kukulies.org), not Let's Encrypt certificates.

3 Likes

Indeed I did run apache also for some time ago.
Currently my haproxy server is stopped since I got a problem with the certificate. haproxy requires to have the private key appended to the fullchain.pem file. And that mechanism failed. That's I was digging around in /etc/letsencrypt/renewal-hooks to find a way to assemble this by a post update script.

I have no idea why I have this episode with this ZeroSSL C=AT certificate. Is a riddle to me.

I wouldn't mind getting certbot totally out of the way when all can be achieved by acme.

You mentioned acme.sh. It's default CA is ZeroSSL. You need to use the --server option for Let's Encrypt with acme.sh

2 Likes

(I edited my previous post by another line)

You say --server. What server then ?

The acme.sh docs would tell you:

4 Likes

So if I'd use acme.sh --issue -d mydomain1.tld -d mydomain2.tld --dns dns_cf --server letsencrypt
the scripts in /etc/letsencrypt/renewal-hooks/deploy apply?

A) where does the --dns dns_cf suddenly come from?

B) why would the Certbot scripts from /etc/letsencrypt/renewal-hooks/deploy suddenly apply to acme.sh? The --server option only changes, well, the used ACME server..

I would recommend to read and learn more about what an ACME server and ACME client is and how they work.

2 Likes

Danb35 introduced it in his reply :slight_smile:

It was part of the example listed in the acme.sh documentation, yes, but why would you use it? The text around the example does not specify it. Do you know what the --dns option does? If not, why not? It's probably mentioned somewhere in the documentation.

2 Likes

When I decide to use --server letsencrypt I wouldn't have to know about ACME server, would I?

It's part of the basic concept of ACME and I would recommend every user of an ACME client to know how ACME in general works.

It's just a recommendation. Do with it what you want. For me personally, as a volunteer of this Community, I expect people coming here for help either already have a basic concept of ACME or are autodidactic enough to start learning about it once they are having trouble.

If I notice someone does not have the slightest interest of educating themselves, so they are able to handle issues in the future by themselves, I personally suddenly loose every motivation to help such a person to be honest :slight_smile: I expect someone coming here for help to also be motivated to do everything in their power to fix the problem, which includes educating themselves.

2 Likes

Clearly, certbot is trying to use Apache.

Please show this file:

2 Likes
# renew_before_expiry = 30 days
version = 2.9.0
archive_dir = /etc/letsencrypt/archive/mail.kukulies.org
cert = /etc/letsencrypt/live/mail.kukulies.org/cert.pem
privkey = /etc/letsencrypt/live/mail.kukulies.org/privkey.pem
chain = /etc/letsencrypt/live/mail.kukulies.org/chain.pem
fullchain = /etc/letsencrypt/live/mail.kukulies.org/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = dfecccbc9a66d368b711f93dd2334490
authenticator = apache
installer = apache
server = https://acme-v02.api.letsencrypt.org/directory
key_type = rsa

@Osiris I understand your criticism. Normally I'm not reluctant reading docs etc.
But please understand that often the situation is such that one follows a recipe from a site, tutorial or sth.
The steps there, e.g. "getting haproxy run with acme.sh" are written down one by one. You follow them step by step and get a result. Like in my case. When using the steps in the tutorial
you don't have read much about the internals and know little about it. Then something isn't functioning like expected and one is seeking advice, like me doing so here.

I would always recommend looking up the purpose of any new and unfamiliar option to a command if you encounter them. Yes, that might cost some time to do, but personally I never run any command with an option I don't know the function of. And personally I would always look up the function of an option before posting online about it :slight_smile: Only if I couldn't find any documentation I would ask about it. But that's just my opinion/method.

2 Likes

Again, a question of understanding:

certbot and acme are two different methods to obtain the (Letsencrypt) certificates, right?
Obviously my certbot is still configured for Apache.

My aim is to run the acme client controlled by haproxy.

No. Certbot is an ACME client. "ACME" is the name of the protocol set out in RFC 8555. There are many ACME clients out there, including "acme.sh" (which is an ACME client written almost entirely in Bash/sh, hence the .sh in the name).

2 Likes