Certificate renewal fails

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: United States COVID-19 Tracker

I ran this command: certbot certonly --force-renew -d www.uscovidtracker.net -v

It produced this output:

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Domain: uscovidtracker.net
  Type:   unauthorized
  Detail: Invalid response from http://uscovidtracker.net/.well-known/acme-challenge/w77LLWX0nl0ia1d8YLEqSwFcmFdA9P6MEe-G-Ms8zaM [98.232.147.26]: "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n         \"http://www."

  Domain: www.uscovidtracker.net
  Type:   unauthorized
  Detail: Invalid response from http://www.uscovidtracker.net/.well-known/acme-challenge/MKIi8h757FUuE41Op_rcjtKIpEy4i75HmGWzDpkOhTs [98.232.147.26]: "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n         \"http://www."

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): Apache 2

The operating system my web server runs on is (include version): Raspbian GNU/Linux 10 (buster)

My hosting provider, if applicable, is: N/A

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): No

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

Hi there again! This post is nearly identical to one that I submitted a little under three months ago (see here). I had a productive exchange there which resolved my issue, and since that point I haven't done anything to modify my configuration.

Almost three months later my cert is about to expire, and I'm trying to renew it but having the same issue all over again. I was hoping that it would auto renew, but the bot sent me an email today saying that the cert is about to expire.

This is a Django website that I serve off my Raspberry Pi (i.e. completely self-hosted).

The output of certbot certificates is:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: uscovidtracker.net
    Serial Number: 4a4953d793c33b0cc3687767ad5d02d70f0
    Key Type: RSA
    Domains: uscovidtracker.net www.uscovidtracker.net
    Expiry Date: 2021-09-23 15:03:56+00:00 (VALID: 3 days)
    Certificate Path: /etc/letsencrypt/live/uscovidtracker.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/uscovidtracker.net/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Any insight, and especially insight as to how I can prevent this again, would be appreciated. Thanks!

1 Like
2

Well, your server responds with:

Server: lighttpd/1.4.53

That could be why Certbot can't renew the certificate: it is trying to us the Apache configuration to perform the renewal, but you're actually hosting your site using lighttpd.

Do you recall installing that in the interval since you installed the certificate?

2 Likes
3

Ah, well...yes. But lighttpd is being used for something else.

My website has to be using Apache. /etc/apache2/sites-enabled/uscovidtracker.net-le-ssl.conf is the only place where WSGIScriptAlias is defined. This parameter defines the entry point into the Django app when a request is made, and it couldn't be coming from anywhere else.

Are Apache and lighttpd stepping over each other somehow?

1 Like
4

In this case, it would seem so, yes.

Either Apache or lighttpd gets to run on port 80. They can't both do it at the same time because they both want to use the port exclusively.

Right now you have:

  • lighttpd running on port 80 (HTTP). (What matters here is that certbot --apache needs Apache to be on port 80 in order to renew successfully)
  • Apache running on port 443 (HTTPS)

I don't know why you have chosen to use two different webservers, but usually there is a way to get a single webserver to do everything you need.

If that isn't possible, the next best step is usually a reverse-proxying kind of configuration. For example, Apache runs on port 80 and proxies requests to lighttpd on e.g. port 8080, or vice versa.

Really it depends on what you're trying to achieve here.

3 Likes
5

I would add also, that if you're happy with the "split" way it is set up right now (for whatever reason), you might be able to get away with something like:

certbot renew --cert-name uscovidtracker.net -a webroot -w /var/www/html

and leave it at that. That should keep working into the future, assuming the webroot path is correct.

2 Likes
6

I have an antenna connected to the Pi that reads air traffic frequencies. It runs the analog signals through a small connector that converts them to digital signals, and special software on the Pi takes those signals and displays the information in an interface, including a map showing where the planes are.

That interface uses lighttpd, and looks for any non-secure port starting with 80. When I set this up, I retained 90 as my non-secure Apache port, per the discussion from a few months ago linked to above, and served the Covid tracker securely through 443. All of this worked fine until I tried to renew the SSL cert last night.

If the cert renewal requires port 80, I could change it but then I don't know what would happen with the other process. It may well be possible to have the aviation interface use Apache too; I just followed the most straightforward procedure for setting it up and configuring it when I got it. The recommendation for that software is to have a Pi dedicated for it alone, but I couldn't see why it wouldn't be possible to have the Pi serve up my Django site simultaneously. Maybe I'm seeing why now.

7

That is only partly correct.
LE can also follow valid redirects (to other protocols or other FQDNs).
So you could also configure lighttpd to redirect uscovidtracker.net & www.uscovidtracker.net to HTTPS.
Then Apache could respond to the challenge requests.

The point is... you have options:

  • lighttpd via --webroot
  • have lighttpd redirect to Apache (to HTTPS)
    a) have Apache plugin handle the rest
    b) use Apache via --webroot
  • use DNS-01
    [a whole other path that doesn't require HTTP(S) validation]
1 Like
8

So I just ended up killing the lighttpd process, moving Apache to port 80, graceful restart, and then the cert renew went through perfectly. Thanks for the insight, it helped tremendously.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: uscovidtracker.net
    Serial Number: 393d4cc071154382ee16aed4d468ebbfd57
    Key Type: RSA
    Domains: uscovidtracker.net www.uscovidtracker.net
    Expiry Date: 2021-12-20 00:05:46+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/uscovidtracker.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/uscovidtracker.net/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
9

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