Webserver on ipv6

Having issues with your DietPi installation or found a bug? Post it here.
User avatar
Joulinar
Posts: 4502
Joined: Sat Nov 16, 2019 12:49 am

Re: Webserver on ipv6

Post by Joulinar »

usually LetsEncrypt will switch off the web server and start an own one to be able to verify the domain.

@MichaIng
can you have a look on this IPv6 issue. Maybe there is something missing to allow LetsEncrypt to valide the DNS
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
trigrhappy
Posts: 27
Joined: Sat Aug 31, 2019 6:38 am

Re: Webserver on ipv6

Post by trigrhappy »

fwiw I've tried running "ss -tulpn | grep lighttpd" in a separate terminal while letsencrypt states that it's listening for the https request...... and it never appears to open port 443 to ipv6 traffic.

EDIT: It seems to be the same problem shown here: viewtopic.php?t=7937

I manually edited the ssl conf in /etc/lighttpd/conf-enabled/ to "[::]:443" similar to the post above and restarted. It opened port 443. I ran letsencrypt, and it errored out at the end. I ran it again and it said the certificate already existed and was current for a long time. I chose not to overwrite...... and my website is now accessible over ipv6. Looks like it actually succeeded in creating the certificate the first time despite the error.

If I can do anything to help fix this bug, please let me know.
User avatar
MichaIng
Site Admin
Posts: 2917
Joined: Sat Nov 18, 2017 6:21 pm

Re: Webserver on ipv6

Post by MichaIng »

The certificate should actually not depend on the IP protocol version but only on the domain. So if you generated a certificate once, and you obviously did, as HTTPS worked over IPv4, then it should work on IPv6 as well with the Lighttpd config change. And AFAIK the config was not changed by dietpi-letsencrypt due to the Certbot failure. That it runs now on IPv6 443 as well basically verifies it.

If you find time, it would be great if you could test the config we use with the new version, where HTTPS via IPv4 and IPv6 should both work:

Code: Select all

cat << '_EOF_' > /etc/lighttpd/conf-available/50-dietpi-https.conf
# Based on: https://ssl-config.mozilla.org/#server=lighttpd
server.modules += ( "mod_openssl" )
# IPv4
$SERVER["socket"] == ":443" {
protocol = "https://"
ssl.engine = "enable"
# pemfile is cert+privkey, ca-file is the intermediate chain in one file
ssl.pemfile = "/etc/letsencrypt/live/your.domain.org/combined.pem"
ssl.ca-file = "/etc/letsencrypt/live/your.domain.org/fullchain.pem"
# For DH/DHE ciphers, dhparam should be >= 2048-bit
#ssl.dh-file = "/path/to/dhparam.pem"
# ECDH/ECDHE ciphers curve strength, see "openssl ecparam -list_curves"
ssl.ec-curve = "secp384r1"
# Environment flag for HTTPS enabled
setenv.add-environment = ( "HTTPS" => "on" )
# Intermediate configuration, tweak to your needs
ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2", "Options" => "-SessionTicket")
ssl.cipher-list = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
ssl.honor-cipher-order = "disable"
ssl.disable-client-renegotiation = "enable"
}
# IPv6
$SERVER["socket"] == "[::]:443" {
protocol = "https://"
ssl.engine = "enable"
# pemfile is cert+privkey, ca-file is the intermediate chain in one file
ssl.pemfile = "/etc/letsencrypt/live/your.domain.org/combined.pem"
ssl.ca-file = "/etc/letsencrypt/live/your.domain.org/fullchain.pem"
# For DH/DHE ciphers, dhparam should be >= 2048-bit
#ssl.dh-file = "/path/to/dhparam.pem"
# ECDH/ECDHE ciphers curve strength, see "openssl ecparam -list_curves"
ssl.ec-curve = "secp384r1"
# Environment flag for HTTPS enabled
setenv.add-environment = ( "HTTPS" => "on" )
# Intermediate configuration, tweak to your needs
ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2", "Options" => "-SessionTicket")
ssl.cipher-list = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
ssl.honor-cipher-order = "disable"
ssl.disable-client-renegotiation = "enable"
}
_EOF_
Replace your.domain.org with our actual domain to point to the correct cert and key files and disable any custom HTTPS-related configs/vhosts, systemctl restart lighttpd) and verify: ss -tulpn | grep 443.

The other question is why Certbot actually failed. The error message does not give a further hint. For retesting this alone, you could force a renewal via:

Code: Select all

certbot renew --force-renew
But it has some rate limiting that should be kept in mind: https://letsencrypt.org/docs/rate-limits/
Especially after 5 failures, you need to wait for 1 hour.

I had while testing two times the case that Certbot failed in the first attempt but succeeded on a subsequent attempt without any changes done on my side. So a failure at least does not necessarily mean that there is a config issue or so ;). But if it fails three times, we'd need to have a closer look why, of course.

@Joulinar
Plugins selected: Authenticator webroot, Installer None
Webroot authentication means that Certbot does not start an own webserver but simply places the test files into the existing webroot of the already running webserver. For Apache2 and Nginx it's similar, although they have own authentication modules, not using the webroot but also the running webservers. Only if no webserver is found, dietpi-letsencrypt will start Certbot in --standalone mode to have it starting up its own.
User avatar
Joulinar
Posts: 4502
Joined: Sat Nov 16, 2019 12:49 am

Re: Webserver on ipv6

Post by Joulinar »

thx for clarification @MichaIng
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Post Reply