# Webserver on ipv6
**URL:** https://dietpi.com/forum/t/webserver-on-ipv6/5243
**Category:** Troubleshooting
**Created:** [26 April 2021 20:13 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243 "2021-04-26T20:13:16Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@trigrhappy](https://dietpi.com/forum/u/trigrhappy)
#### Post date: [26 April 2021 20:13 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/1 "2021-04-26T20:13:16Z")
So I’ve been hosting my content on ipv4, but have made the move to SpaceX’s Starlink satellite internet (the upload speeds alone are usually in excess of 70mb!). The problem is the ipv4 is behind a CGNAT, but since it has working ipv6 I don’t need to worry about NAT at all anymore. So I’ve written a cronjob to update my ipv6 IP with Google Domains (which my domain is registered on) and verified that it registers the proper IPV6 address.
The issue I have now as that it simply doesn’t work. I suspect that I must open port 80 specifically on my IPV6, but I don’t know where to begin. I verified port 80 is open and available (and that my website etc is working properly on port 80 from its ipv4 address on my LAN. I’m using lighttpd.
Any advice is appreciated.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [26 April 2021 20:56 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/2 "2021-04-26T20:56:07Z")
Hi,
not sure if you already did but I guess you would need to activate port forwarding on IPv6 on your internet router or at least define the port to be forwarded on IPv6.
---
### Author:  [@trigrhappy](https://dietpi.com/forum/u/trigrhappy)
#### Post date: [26 April 2021 21:03 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/3 "2021-04-26T21:03:28Z")
No port forwarding is necessary on ipv6 since the connection is directly from the client to the server. The router can block or allow traffic to or from any computer connected behind it (in a native IPV6 environment, the “router” is essentially just a hardware firewall), but there’s no conventional address translation or forwarding to be done.
I’ve verified that port 80 is not blocked to the dietpi server (on neither ipv4 nor ipv6) from any client.
Dietpi-config network/adapter options do not display any ipv6 information (just that it is enabled)… When I select “Ethernet Details” only ipv4 information is displayed. I don’t know if its related to my webserver on port 80 not being accessible via ipv6, but it is worth mentioning.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [26 April 2021 21:11 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/4 "2021-04-26T21:11:29Z")
but still the port would need to be open on your router. Isn’t it? Otherwise it would mean you server is fully expose to the internet.
As well you could check if your web server is listen on the IPv6 address.
```nohighlight
ss -tulpn | grep LISTEN
```
---
### Author:  [@trigrhappy](https://dietpi.com/forum/u/trigrhappy)
#### Post date: [26 April 2021 21:28 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/5 "2021-04-26T21:28:42Z")
Yes, on my router i have specifically set all connections to port 80 be allowed to my server’s ipv6 address.
```nohighlight
root@superDietPi:~# ss -tulpn | grep LISTEN
tcp LISTEN 0 50 0.0.0.0:58846 0.0.0.0:* users:(("deluged",pid=21597,fd=17))
tcp LISTEN 0 64 0.0.0.0:44703 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:44735 0.0.0.0:* users:(("rpc.mountd",pid=21346,fd=17))
tcp LISTEN 0 5 0.0.0.0:6881 0.0.0.0:* users:(("deluged",pid=21597,fd=13))
tcp LISTEN 0 64 0.0.0.0:2049 0.0.0.0:*
tcp LISTEN 0 100 0.0.0.0:6789 0.0.0.0:* users:(("nzbget",pid=21582,fd=5))
tcp LISTEN 0 128 0.0.0.0:52133 0.0.0.0:* users:(("rpc.mountd",pid=21346,fd=9))
tcp LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* users:(("mysqld",pid=21457,fd=40))
tcp LISTEN 0 128 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=21375,fd=7))
tcp LISTEN 0 128 0.0.0.0:54123 0.0.0.0:* users:(("rpc.mountd",pid=21346,fd=13))
tcp LISTEN 0 50 0.0.0.0:139 0.0.0.0:* users:(("smbd",pid=21325,fd=32))
tcp LISTEN 0 5 0.0.0.0:5901 0.0.0.0:* users:(("Xtigervnc",pid=768,fd=7))
tcp LISTEN 0 128 0.0.0.0:8686 0.0.0.0:* users:(("mono",pid=21671,fd=8))
tcp LISTEN 0 128 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=394,fd=4),("systemd",pid=1,fd=56))
tcp LISTEN 0 128 0.0.0.0:10000 0.0.0.0:* users:(("miniserv.pl",pid=21770,fd=5))
tcp LISTEN 0 50 0.0.0.0:8112 0.0.0.0:* users:(("deluge-web",pid=21685,fd=5))
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("lighttpd",pid=21555,fd=4))
tcp LISTEN 0 128 0.0.0.0:8084 0.0.0.0:* users:(("mono",pid=478,fd=5))
tcp LISTEN 0 10 0.0.0.0:8085 0.0.0.0:* users:(("python",pid=21781,fd=5))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("dropbear",pid=739,fd=3))
tcp LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("lighttpd",pid=21555,fd=6))
tcp LISTEN 0 128 0.0.0.0:8989 0.0.0.0:* users:(("mono",pid=21650,fd=10))
tcp LISTEN 0 50 0.0.0.0:445 0.0.0.0:* users:(("smbd",pid=21325,fd=31))
tcp LISTEN 0 128 *:8096 *:* users:(("EmbyServer",pid=21613,fd=231))
tcp LISTEN 0 5 [::]:6881 [::]:* users:(("deluged",pid=21597,fd=12))
tcp LISTEN 0 64 [::]:2049 [::]:*
tcp LISTEN 0 128 [::]:56737 [::]:* users:(("rpc.mountd",pid=21346,fd=19))
tcp LISTEN 0 128 *:7878 *:* users:(("Radarr",pid=21663,fd=206))
tcp LISTEN 0 128 [::]:37255 [::]:* users:(("rpc.mountd",pid=21346,fd=11))
tcp LISTEN 0 128 [::]:58569 [::]:* users:(("rpc.mountd",pid=21346,fd=15))
tcp LISTEN 0 128 [::1]:6379 [::]:* users:(("redis-server",pid=21375,fd=8))
tcp LISTEN 0 50 [::]:139 [::]:* users:(("smbd",pid=21325,fd=30))
tcp LISTEN 0 64 [::]:45005 [::]:*
tcp LISTEN 0 5 [::]:5901 [::]:* users:(("Xtigervnc",pid=768,fd=8))
tcp LISTEN 0 128 [::]:111 [::]:* users:(("rpcbind",pid=394,fd=6),("systemd",pid=1,fd=58))
tcp LISTEN 0 128 [::]:80 [::]:* users:(("lighttpd",pid=21555,fd=5))
tcp LISTEN 0 128 *:21 *:* users:(("proftpd",pid=21303,fd=0))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("dropbear",pid=739,fd=4))
tcp LISTEN 0 128 *:9117 *:* users:(("jackett",pid=9036,fd=190))
tcp LISTEN 0 50 [::]:445 [::]:* users:(("smbd",pid=21325,fd=29))
```
I take from that:
```nohighlight
tcp LISTEN 0 128 [::]:80 [::]:* users:(("lighttpd",pid=21555,fd=5))
```
Likely means yes, it’s listening?
---
### Author:  [@trigrhappy](https://dietpi.com/forum/u/trigrhappy)
#### Post date: [26 April 2021 21:50 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/6 "2021-04-26T21:50:27Z")
I’ve verified that the ipv6 address is live by manually entering it into a web browser and connecting to my open Emby instance.
When I try to connect to port 80, it simply says “Connection Refused”. I did notice that it’s automatically appending “https://” to the front of the address, even when I change it to “http://”. That makes me suspect it’s an ssl issue. Unfortunately, I’m not able to run dietpi-letsencrypt to get a new certificate since it says its publicly inaccessable.
I’ll continue troubleshooting tomorrow. Thank you for all of your help thus far!
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [26 April 2021 22:07 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/7 "2021-04-26T22:07:46Z")
yes lighttpd is LISTEN on IPv6 port 80 but on 80 only. It would need to listen on port 443 as well. Like it is on IPv4
```nohighlight
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("lighttpd",pid=21555,fd=4))
tcp LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("lighttpd",pid=21555,fd=6))
```
I guess you activated http \> https redirect on dietpi-letsencrypt. Therefore you will be forwarded to https, always.
Maybe your issue will be addressed on next DietPi release already. At least there is note on the changelog for current BETA
[https://github.com/MichaIng/DietPi/blob/898cfcbcb11df64ff0d87f2d63c7deaba7d10030/CHANGELOG.txt#L12](https://github.com/MichaIng/DietPi/blob/898cfcbcb11df64ff0d87f2d63c7deaba7d10030/CHANGELOG.txt#L12)
---
### Author:  [@trigrhappy](https://dietpi.com/forum/u/trigrhappy)
#### Post date: [27 April 2021 16:24 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/8 "2021-04-27T16:24:30Z")
Updated to the beta. Still no dice.
```nohighlight
DietPi v7.1.1 (beta) : 18:22 - Tue 04/27/2021
─────────────────────────────────────────────────────
- Device model : Native PC (x86_64)
- LAN IP : 192.168.0.3 (eth0)
- Freespace (RootFS) : 309G
- MOTD : Open Beta v7.1, please help testing the upcoming release:
https://github.com/MichaIng/DietPi/issues/4294
─────────────────────────────────────────────────────
DietPi Team : MichaIng (lead), Daniel Knight (founder), Joulinar (support)
Image by : DietPi Core Team (pre-image: Debian mini.iso)
Web : https://dietpi.com | https://twitter.com/DietPi_
Patreon Legends : Camry2731
Contribute : https://dietpi.com/contribute.html
DietPi Hosting : Powered by https://myvirtualserver.com
dietpi-launcher : All the DietPi programs in one place.
dietpi-config : Feature rich configuration tool for your device.
dietpi-software : Select optimized software for installation.
htop : Resource monitor.
cpu : Shows CPU information and stats.
root@superDietPi:~# ss -tulpn | grep LISTEN
tcp LISTEN 0 100 0.0.0.0:6789 0.0.0.0:* users:(("nzbget",pid=1864,fd=6))
tcp LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* users:(("mysqld",pid=1765,fd=19))
tcp LISTEN 0 128 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=1694,fd=7))
tcp LISTEN 0 50 0.0.0.0:139 0.0.0.0:* users:(("smbd",pid=789,fd=32))
tcp LISTEN 0 5 0.0.0.0:5901 0.0.0.0:* users:(("Xtigervnc",pid=771,fd=7))
tcp LISTEN 0 128 0.0.0.0:8686 0.0.0.0:* users:(("mono",pid=1893,fd=8))
tcp LISTEN 0 128 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=394,fd=4),("systemd",pid=1,fd=33))
tcp LISTEN 0 128 0.0.0.0:10000 0.0.0.0:* users:(("miniserv.pl",pid=1977,fd=5))
tcp LISTEN 0 50 0.0.0.0:8112 0.0.0.0:* users:(("deluge-web",pid=1900,fd=5))
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("lighttpd",pid=1850,fd=4))
tcp LISTEN 0 64 0.0.0.0:34769 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:44625 0.0.0.0:* users:(("rpc.mountd",pid=828,fd=9))
tcp LISTEN 0 128 0.0.0.0:8084 0.0.0.0:* users:(("mono",pid=476,fd=5))
tcp LISTEN 0 10 0.0.0.0:8085 0.0.0.0:* users:(("python",pid=1981,fd=5))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("dropbear",pid=717,fd=3))
tcp LISTEN 0 128 0.0.0.0:53337 0.0.0.0:* users:(("rpc.mountd",pid=828,fd=17))
tcp LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("lighttpd",pid=1850,fd=6))
tcp LISTEN 0 128 0.0.0.0:58971 0.0.0.0:* users:(("rpc.mountd",pid=828,fd=13))
tcp LISTEN 0 128 0.0.0.0:8989 0.0.0.0:* users:(("mono",pid=1887,fd=10))
tcp LISTEN 0 50 0.0.0.0:445 0.0.0.0:* users:(("smbd",pid=789,fd=31))
tcp LISTEN 0 50 0.0.0.0:58846 0.0.0.0:* users:(("deluged",pid=1875,fd=17))
tcp LISTEN 0 5 0.0.0.0:6881 0.0.0.0:* users:(("deluged",pid=1875,fd=13))
tcp LISTEN 0 64 0.0.0.0:2049 0.0.0.0:*
tcp LISTEN 0 128 *:7878 *:* users:(("Radarr",pid=1890,fd=206))
tcp LISTEN 0 128 [::1]:6379 [::]:* users:(("redis-server",pid=1694,fd=8))
tcp LISTEN 0 50 [::]:139 [::]:* users:(("smbd",pid=789,fd=30))
tcp LISTEN 0 64 [::]:44429 [::]:*
tcp LISTEN 0 5 [::]:5901 [::]:* users:(("Xtigervnc",pid=771,fd=8))
tcp LISTEN 0 128 [::]:111 [::]:* users:(("rpcbind",pid=394,fd=6),("systemd",pid=1,fd=35))
tcp LISTEN 0 128 [::]:80 [::]:* users:(("lighttpd",pid=1850,fd=5))
tcp LISTEN 0 128 [::]:56565 [::]:* users:(("rpc.mountd",pid=828,fd=11))
tcp LISTEN 0 128 *:21 *:* users:(("proftpd",pid=772,fd=0))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("dropbear",pid=717,fd=4))
tcp LISTEN 0 128 *:9117 *:* users:(("jackett",pid=1910,fd=190))
tcp LISTEN 0 50 [::]:445 [::]:* users:(("smbd",pid=789,fd=29))
tcp LISTEN 0 128 [::]:59199 [::]:* users:(("rpc.mountd",pid=828,fd=19))
tcp LISTEN 0 128 *:8096 *:* users:(("EmbyServer",pid=1880,fd=231))
tcp LISTEN 0 5 [::]:6881 [::]:* users:(("deluged",pid=1875,fd=12))
tcp LISTEN 0 64 [::]:2049 [::]:*
tcp LISTEN 0 128 [::]:48385 [::]:* users:(("rpc.mountd",pid=828,fd=15))
root@superDietPi:~#
```
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [27 April 2021 16:38 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/9 "2021-04-27T16:38:24Z")
Hi,
I guess you would need to rerun dietpi-letsencrypt as the change will be done on this script if I’m not mistaken
To make it easier to filter on Lighttpd, you could use following command.
```nohighlight
ss -tulpn | grep lighttpd
```
---
### Author:  [@trigrhappy](https://dietpi.com/forum/u/trigrhappy)
#### Post date: [27 April 2021 16:49 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/10 "2021-04-27T16:49:50Z")
So I’ve verified that my domain is reachable at its registered domain name using [https://ipv6-test.com/validate.php](https://ipv6-test.com/validate.php). It returns my correct ipv6 associated address and the correct version of lighttpd, but unfortunately, letsencrypt fails:
```nohighlight
DietPi-LetsEncrypt
─────────────────────────────────────────────────────
Mode: Running Certbot
[OK] DietPi-LetsEncrypt | Lighttpd webserver detected
[OK] DietPi-LetsEncrypt | systemctl start lighttpd
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.NotMyActualWebsite.com
Using the webroot path /var/www for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.NotMyActualWebsite.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.NotMyActualWebsite.com/.well-known/acme-challenge/olhoB0uy-eJBxKXc3zVq7CJ5Exc2mmpKmGsfC_eWNCU: Connection refused
```
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [27 April 2021 17:24 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/11 "2021-04-27T17:24:21Z")
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
---
### Author:  [@trigrhappy](https://dietpi.com/forum/u/trigrhappy)
#### Post date: [27 April 2021 17:53 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/12 "2021-04-27T17:53:45Z")
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: [https://dietpi.com/forum/t/lets-encrypt-for-ipv6-only-websites/4334/1](https://dietpi.com/forum/t/lets-encrypt-for-ipv6-only-websites/4334/1)
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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [27 April 2021 20:11 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/13 "2021-04-27T20:11:41Z")
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:
```plaintext
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](http://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:
```plaintext
certbot renew --force-renew
```
But it has some rate limiting that should be kept in mind: [Rate Limits - Let's Encrypt](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.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [27 April 2021 20:24 UTC](https://dietpi.com/forum/t/webserver-on-ipv6/5243/14 "2021-04-27T20:24:35Z")
thx for clarification MichaIng