I have been running lighty on my development machine for some years now, have set up some vhosts, one of them is phpmyadmin and one of the others uses SSL with a self-signed certificate on certain pages; and it has been working fine for years.
But now, every time I try to access either of my vhosts, the browsers just show me an error message claiming that the server is not correctly configured and uses hsts (NET::ERR_CERT_AUTHORITY_INVALID) - but I never set that up!
http://(ip-address)/ works fine; as does http://(ip-address)/vhost-path/, and I would work with that until I throw lighty in the bin and install nginx; but the redirects render that unusable at some point in the testing.
I had the idea that the AV software on my Windows client might cause the problem; but it also shows on the Debian development machine itself.
Any ideas on how this comes and how to fix the issue?
contents of /etc/conf/lighttpd/conf-enabled:
05-auth.conf
10-fastcgi.conf
10-ssl.conf
50-phpmyadmin.conf
10-cgi.conf
10-simple-vhost.conf
15-fastcgi-php.conf
90-javascript-alias.conf
As far as I remember, only 10-ssl.conf contains more than the default content; and they all haven´t been modified in years.
lighttpd.conf (mtime two years ago) contains:
server.modules = (
"mod_access",
"mod_accesslog",
"mod_alias",
"mod_compress",
"mod_redirect",
)
... (general server setup) ...
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
... (vhost configuration) ...
/etc/conf/lighttpd/ssl/ contains the SSL certificate for the one vhost I use https on (valid until somewhere in 2023).
Chrome own the .dev TLD and decided to preload this into the static HSTS list baked into the browser. Firefox followed suite recently. See this link for more info: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
This means you cannot turn of HSTS.
Your options are:
Note that since HSTS will not allow you to click through certificate errors you also need to add the certificate (or the issues) to the trust store.
It's my strong opinion that development should be done on HTTPS sites. This matches production, so avoids problems with mixed content when you go live, certain powerful features will not work on HTTP-only sites, and similarly with certain new features (HTTP/2, Brotli compression, Service Workers).
Do yourself a favour and just create a self-signed cert, add it to your trust store, and move to HTTPS for development. Note also that Chrome requires certificates to have the SAN field which takes a bit more effort but can be completed with this on linux (replace the two instances of server.domain.tld):
openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.key \
-new \
-out server.crt \
-subj /CN=server.domain.tld\
-reqexts SAN \
-extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf\<(printf '[SAN]\nsubjectAltName=DNS:server.domain.tld')) \
-sha256 \
-days 3650
Or alternatively on MacOS where you can't use the onliner:
cat /System/Library/OpenSSL/openssl.cnf > /tmp/openssl.cnf
echo '[SAN]\nsubjectAltName=DNS:server.domain.tl'>> /tmp/openssl.cnf
openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.key \
-new \-out server.crt \
-subj /CN=server.domain.tl\
-reqexts SAN \
-extensions SAN \
-config /tmp/openssl.cnf\
-sha256 \
-days 3650