On 31/8/21 6:10 am, apache-httpd-users@xxxxxxxxxxxxxxx wrote:
I wasn't expecting (and wouldn't want) a cert for an IP address, particularly seeing mine is not static. What I am looking for is something I could put into a RewriteCond on the first *:443 vhost to trap that condition. Maybe an empty HTTP_HOST ?Hi Peter, On 30.08.21 04:24, Peter Horn wrote:I have been successfully running an Apache server for some years (currently 2.4.41 on Ubuntu 20.04LTS). I have three "real" http vhosts on port 80, findable through a dynamic DNS service. I also have a (first in line) default vhost with an "unreachable" ServerName, which returns a 4xx status, and exposes the request to fail2ban. This takes care of the script kiddies and IOT bug-probers who access by IP address, not hostname. Recently I upgraded to https on port 443, using LetsEncrypt and CertBot. The transition went smoothly; http requests to the vhosts on port 80 are returned a 301 redirect permanent to https. I have two questions: 1. Can I implement the same "nameless catchall" in the https environment, or does the vhost selection work differently there? My ssl cert appears to name all three real vhosts, but I am unsure what happens when a request doesn't match any of them.The cert you are using lists only these three names (you could check via "openssl x509 -in <certfile> -noout -text"). All connections using IP addresses or names not part of the cert should fail on TLS handshake (at least if certificate is validated by the client). You might catch clients, which do not validate certificates with your current TLS setup (that would be clients connecting using IP). Clients that validate the certificate will not send the actual request. Let's encrypt does not issue certificates for IP addresses (https://community.letsencrypt.org/t/ssl-on-a-ip-instead-of-domain/90635/3), so you can not simply add your IP to the certificate.
I'll leave http / port 80 for a while, and keep an eye on legitimate traffic (that would be redirected). I'll have a look at Strict-Transport-Security.2. Are there any adverse consequences to closing down http / port 80 now that the vhosts are up on https / port 443?That depends, new browsers versions are currently changing their behaviour on site access (e.g. see https://blog.mozilla.org/security/2021/08/10/firefox-91-introduces-https-by-default-in-private-browsing/, https://www.bleepingcomputer.com/news/google/google-chrome-90-released-with-https-as-the-default-protocol/). Older Browsers try HTTP (port 80) before trying HTTPS (port 443), some even do not try HTTPS, if the initial HTTP fails. YMMV. I'd suggest to keep the HTTP vhost for pure redirects and additionally set the Strict-Transport-Security header (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) on HTTPS requests. With the header, most browsers will cache the information that HTTPS is enabled for your site and even enforce it for the time you set in the header.
hth. Thomas
Thank you, Peter --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|