Certbot -renew -apache failed

Help
1

The certbot SSL worked perfect so far, but when I try to renew certification it does not work.
My domain is: hagerty.ddns.net

I ran this command: sudo certbot renew -apache

It produced this output:
sudo certbot renew -apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/hagerty.ddns.net.conf

Cert is due for renewal, auto-renewing...
Could not choose appropriate plugin: The requested pache plugin does not appear to be installed
Attempting to renew cert (hagerty.ddns.net) from /etc/letsencrypt/renewal/hagerty.ddns.net.conf produced an unexpected error: The requested pache plugin does not appear to be installed. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/hagerty.ddns.net/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/hagerty.ddns.net/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

My web server is (include version):
Server version: Apache/2.4.41 (Ubuntu)
Server built: 2023-03-08T17:32:54
The operating system my web server runs on is (include version):
running on Ubuntu 20.04

Do not have hosting provider

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): I am using Ubuntu terminal command line (Ctrl alt t).
sudo certbot plugins
[sudo] password for tietz:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

  • apache
    Description: Apache Web Server plugin
    Interfaces: IAuthenticator, IInstaller, IPlugin
    Entry point: apache = certbot_apache.entrypoint:ENTRYPOINT

  • standalone
    Description: Spin up a temporary webserver
    Interfaces: IAuthenticator, IPlugin
    Entry point: standalone = certbot.plugins.standalone:Authenticator

  • webroot
    Description: Place files in webroot directory
    Interfaces: IAuthenticator, IPlugin
    Entry point: webroot = certbot.plugins.webroot:Authenticator

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

The error message is not meaningfull at all because this command:
sudo certbot plugins
shows that the requested apache plugin IS INSTALLED!!!!
[sudo] password for tietz:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

  • apache
    Description: Apache Web Server plugin
    Interfaces: IAuthenticator, IInstaller, IPlugin
    Entry point: apache = certbot_apache.entrypoint:ENTRYPOINT

  • standalone
    Description: Spin up a temporary webserver
    Interfaces: IAuthenticator, IPlugin
    Entry point: standalone = certbot.plugins.standalone:Authenticator

  • webroot
    Description: Place files in webroot directory
    Interfaces: IAuthenticator, IPlugin
    Entry point: webroot = certbot.plugins.webroot:Authenticator

Can you please help. In a couple of days the certificate is invalid. What is the solution?
regards
h.g.

2

Would you show the contents of this conf file please

Also, you normally don't add any options to the certbot renew command.

And, the cert your site is using expires on May18 and not "in a couple days". So you have some time to sort it.

4 Likes
3

cat /etc/letsencrypt/renewal/hagerty.ddns.net.conf

# renew_before_expiry = 30 days
version = 0.40.0
archive_dir = /etc/letsencrypt/archive/hagerty.ddns.net
cert = /etc/letsencrypt/live/hagerty.ddns.net/cert.pem
privkey = /etc/letsencrypt/live/hagerty.ddns.net/privkey.pem
chain = /etc/letsencrypt/live/hagerty.ddns.net/chain.pem
fullchain = /etc/letsencrypt/live/hagerty.ddns.net/fullchain.pem

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

I also tried "sudo certbot renew"
But same failure.

4

The apache plug-in was installed at one time. You wouldn't have those values in your renewal config if it never worked. So, what changed?

You might just be better off replaced v0.40 with the recommended snap version of certbot (currently v2.5)

Follow the instructions closely

3 Likes
5

I do not understand. The certbot renew never worked. So the ? is obsolete.
I assume to install cerbot with snap I first have to uninstall the current certbot on my system. Is that correct?

6

Yes, follow the instructions on the install page I linked to update Certbot to snap.

The renewal conf file gets created when you first get a valid cert. It is then used on later renew requests. So, the apache plug-in must have worked for you to get the initial cert. Something happened to it since.

3 Likes
7

Then something changed/broke in your Apache configuration [or something else] between the time you obtained the cert [February 17] and the time it should have renewed [60 days later].

Renewals are done exactly how initial certificates are issued.
We say "renew" cert, but, in actuality, it is just another cert "issuance".
[it is just using the exact same set of names]

So, the first 'issuance" worked, and the second "issuance" failed.
Since, the certbot configuration did not change [it won't], they both did the exact same thing.
So, what else has changed?

3 Likes
8

So, I reinstalled certbot and apache and got:
sudo certbot --apache
[sudo] password for tietz:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): hagerty.ddns.net
Requesting a certificate for hagerty.ddns.net

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/hagerty.ddns.net/fullchain.pem
Key is saved at: /etc/letsencrypt/live/hagerty.ddns.net/privkey.pem
This certificate expires on 2023-08-01.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for hagerty.ddns.net to /etc/apache2/sites-available/000-default-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://hagerty.ddns.net

If you like Certbot, please consider supporting our work by:

So it is still working - now maybe till 2023-08-01 . But I do not know whether the renew process is working. Above msg says "Certbot has set up a scheduled task to automatically renew this certificate in the background." Does it mean it is not necessary anymore to issue "certbot renew" from my system?

9

The scheduled task installed by Certbot will run renew for you.

You can test it by running

sudo certbot renew --dry-run

That will test the process but will not affect your existing certs or Apache

5 Likes
10

Thank you very much, you helped me very much. It is working now.
And I found the reason for the problem.
When I got the certification I inactivated on my router the http port 80 forwarding to my system and that works fine till I start the certbot renew .
Then I have to make my system unsecure for the certbot renew process time. That does not make sense to me.

1 Like
11

Your statement doesn't make sense to me.
What do you mean "make my system unsecure"?

4 Likes
12

I make my system unsecure when I allow http and I have to to allow http when I need "certbot renew".
HTTPS: What are the differences? HTTPS is HTTP with encryption and verification. The only difference between the two protocols is that HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses, and to digitally sign those requests and responses . As a result, HTTPS is far more secure than HTTP.

13

Well, yes, but only the ACME HTTP Challenge is being handled there and it has its own security precautions. This topic discusses your concern. Let us know if you still have concerns after that

4 Likes
14

For private use it might be ok.
But for my customer "It is a no way":
Defining just for "certbot renew" a http server to forward a port to different servers on the router and open the firewall on each server for port 80 for INPUT and OUTPUT chain. It is additional maintenance effort for opening and closing the firewall door and a good chance for Murphys law.

15

Then you won't be able to use the HTTP Challenge. The DNS Challenge or TLS-ALPN are options.

You should also look at the mod_md feature in Apache. It supports all 3 challenge types and you use that instead of Certbot. These are the 2.5 docs for Apache but it has been part of Apache since 2.4.30. A skilled Apache admin would probably even find this easier to use than Certbot. There is also a helpful github (link here)

Apache mod_md docs:
https://httpd.apache.org/docs/trunk/mod/mod_md.html

5 Likes
16

The customer web service should be run on 443.
The ACME web service should be run on port 80.
They don't need to be run by the same program; Nor on the same system.
Nor does HTTP even really need to be listening at all times - if you don't care to redirect HTTP to HTTPS.

You could simple use the ACME client in a standalone mode.
Thus, even though the HTTP port is open, nothing will be listening on it [until it needs to renew a cert].

If the web service is already bound to port 80, you could NAT the external port 80 to some unused internal port [or to some other system].

3 Likes
17

But but but.. Port 80 is EEEEEEEEEEEEEEEEVIL!!! And DAAAAAAAANGEROUS! Insert childish voice here

1 Like
18

Yes, that is where all the BIOS POST code go. :rofl:

2 Likes
19

No, you don't. Despite being widely believed, this statement is objectively false. You're naturally free to misconfigure your system in whatever way seems good to you, but those configuration decisions have consequences. But nothing about accepting HTTP connections on port 80 makes your system any less secure than not.

Then your customer (really? you have a "customer" with a ddns.net address?) is behaving foolishly, perhaps because they've been advised foolishly.

The bottom line is that the web runs on port 80. The day may come when browsers try to connect by default via HTTPS on port 443, but this is not that day--nor, IMO, is this that decade. If you're going to have publicly-available web services, your web server should be listening and responding on port 80--and redirecting to HTTPS on 443.

As noted up-topic, yes, there are other challenge types that don't require port 80 to be open. Certbot even supports one of those. But "port 80 is insecure" is false, and closing it on a server that's supposed to be on the public Internet is unwise.

4 Likes
20

There are other Free ACME Certificate Authorities as well
Some of them possibly do not have the Port 80 requirement.

ACME CA Comparison - Posh-ACME

2 Likes