When trying to connect to some of my webservers with HTTPS (I followed the guide and used dietpi-LetsEncrypt to set it up) I get the error “SSL_ERROR_RX_RECORD_TOO_LONG”. Does anyone know why this is happening?
What webserver do you use? Does it happen with every browser?
some more information would be helpful. What does my webservers mean? Which application you are trying to access? As well can you share some more details on your system
#### Required
- DietPi version | `cat /boot/dietpi/.version`
- Distro version | `echo $G_DISTRO_NAME $G_RASPBIAN`
- Kernel version | `uname -a`
- Architecture | `dpkg --print-architecture`
- SBC model | `echo $G_HW_MODEL_NAME` or (EG: RPi3)
This happens when trying to connect to dietpi-dashboard and AdGuard Home’s webpages/webservers via HTTPS. They work fine via HTTP, though.
The domain that im using is made with FreeDNS and has Dynamic DNS on.
It happens when trying to connect to the AdGuard Home dashboard and dietpi-dashboard. I’ve tried connecting on both Firefox and Safari.
There seems to be a misunderstanding on your side about how dietpi-letsencrypt works and what it does.
By default, it only creates SSL certificates and configures web server applications like Apache or Nginx to use them. Our script will not configure anything for other applications like Dashboard or AGH. Normally, all applications except the web server need to be configured manually and individually. Alternatively, a reverse proxy can be set up. By the way, our Dashboard does not currently support reverse proxy scenarios.
Oh. Okay. Thanks for the help anyways!
Are you trying to access from inside or outside your network?
If from inside…http is fine (unless you have unauthorized people in your home network!)
If from outside…I recommend using a cloudflare tunnel, it is what I use and it works suprisingly well
Watch this first
Then watch the howto setup…for 99% of “home users” (using of the shelf router and NAT firewalling) it’s more than fine…for commercial/enterprise…not no…but HELL NO!
Then watch this
There is also a further step that can lock the zero trust tunnel down further…
