bug#62491: [berlin] certbot renewal appears to be broken

[Giovanni Biscuolo]

Hello Attila,

I'm starting using certbot on a new Guix System server of mine: I've not
much experience with this Guix service but I'm using certbot on other
machines so I hope I can help here.

Attila Lendvai <attila@lendvai.name> writes:

> i don't think this is the same issue as #56678.

AFAIU actually #56678 is (was?) caused by a duplicate certbot account:

--8<---------------cut here---------------start------------->8---

Please choose an account
Choices: ['guix-hpc.bordeaux.inria.fr@2017-09-04T08:51:13Z (48c5)',
'localhost@2016-12-03T21:08:38Z (00bc)']

--8<---------------cut here---------------end--------------->8---

on bayfront, probably caused by some "manual" certbot invocation (I'm
guessing, I cannot have a look to /etc/letsenctypt)

Lodo' please: has that issue (#56678) been solved and how?

The problem on berlin (#62491) is (was) due to a failed challenge:

--8<---------------cut here---------------start------------->8---

2023-03-24 00:33:09 127768 certbot renew --webroot --webroot-path /var/www: 
Hint: The
Certificate Authority failed to download the temporary challenge files created 
by Certbot.
Ensure that the listed domains serve their content from the provided 
--webroot-path/-w and
that files created there can be downloaded from the internet.
2023-03-24 00:33:09 127768 certbot renew --webroot --webroot-path /var/www: 
2023-03-24 00:33:09 127768 certbot renew --webroot --webroot-path /var/www: 
Failed to renew
certificate disarchive.guix.gnu.org with error: Some challenges have failed.

--8<---------------cut here---------------end--------------->8---

Maxim please: has that issue (#62491) been solved and how?

[...]

> this is the mcron that gets generated:
> [...]/certbot certonly -n --agree-tos --webroot -w /srv/http/ --cert-name 
> dwim.hu -d dwim.hu --email attila@lendvai.name

Did you specify a different webroot?  The default one defined in
"certbot-configuration" is "/var/www".

This is my certbot service config:

--8<---------------cut here---------------start------------->8---

            (service certbot-service-type
                     (certbot-configuration
                      (email "giovanni@biscuolo.net")
                      (certificates
                       (list
                        (certificate-configuration
                         (domains '("mx01.biscuolo.net")))))))

--8<---------------cut here---------------end--------------->8---

This is the certbot command that gets generated (and is scheduled in my
mcron):

--8<---------------cut here---------------start------------->8---

#!/gnu/store/x4m56h5qkim0pnvx6vgvp541mrdwdrah-guile-3.0.9/bin/guile 
--no-auto-compile
!#
(begin (use-modules (ice-9 match)) (let ((code 0)) (for-each (match-lambda 
((name . command) (begin (format #t "Acquiring or renewing certificate: ~a~%" 
name) (set! code (or (apply system* command) code))))) (quote 
(("mx01.biscuolo.net" 
"/gnu/store/8vs33jaqpjkr5mzpz8syxvz2w472s5w7-certbot-2.3.0/bin/certbot" 
"certonly" "-n" "--agree-tos" "--webroot" "-w" "/var/www" "--cert-name" 
"mx01.biscuolo.net" "-d" "mx01.biscuolo.net" "--email" 
"giovanni@biscuolo.net")))) code))

--8<---------------cut here---------------end--------------->8---

Also, this is the "server" config for the generated nginx configuration:

--8<---------------cut here---------------start------------->8---

    server {
      listen 80;
      listen [::]:80;
      server_name mx01.biscuolo.net ;
      root /srv/http;
      index index.html ;
      server_tokens off;

      location /.well-known {
        root /var/www;
      }
      location / {
        return 301 https://$host$request_uri;
      }

    }

--8<---------------cut here---------------end--------------->8---

> and this what worked when i fixed the -w arg:

What was the error before you fixed the -w arg?

How was the nginx service configured?

> [...]/certbot certonly -n --agree-tos --webroot -w /srv/http/dwim.hu 
> --cert-name dwim.hu -d dwim.hu --email attila@lendvai.name
>
> i.e. the -w parameter should point to the webroot of the virtual
> domain,

No: that webroot is the directory from which to serve the Let’s Encrypt
challenge/response files, it have nothing do do with the webroot of the
corresponding virtual domain served by *another* nginx service (or other
service using the certificate)

> but the guix config structure does not allow setting the webroot for
> each <certificate-configuration>, only at their parent, i.e. in the
> <certbot-configuration>.

AFAIU there is no need to set a certbot webroot for each certificate:
one webroot can serve all the challenge/response files needed for each
certificate, since certbot creates a unique subfolder in /.well-known
for each of them.

[...]

> from the certbot log (i.e. challenge is saved at the wrong path):
>
> "Removing /srv/http/.well-known/acme-challenge/[hash]"

Why do you say that challenge is in the wrong path?

It works that way :-)

[...]

WDYT?

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature