Apache virtual host redirect issue [duplicate] - apache

Question

This question already has answers here:
Is it possible to have SSL certificate for IP address, not domain name? [closed]
(7 answers)
Closed 10 months ago.
I'm trying to host a site on my server(vultr) The site is live and I have a domain name from Namecheap pointed to it. I have used Let's Encrypt and have https for www.example.com and example.com.
I also have it set so when you enter the ip like: http://111.222.33.444 it directs to the secured domain name. So everything up to this point works just as I expected, but then I encounter this problem: if someone enters https:///111.222.33.444 the untrusted website warning page comes up. I want this to also just direct to https://example.com.
I have .conf files for http and https. I probably also have too much rubbish in these files, so probably need to write these more efficiently.
home.conf:
<VirtualHost *:80>
ServerAdmin admin#example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/html/home
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.example.com [OR]
RewriteCond %{SERVER_NAME} =example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:80>
ServerName 111.222.33.444
ServerAlias 111.222.33.444
UseCanonicalName Off
Redirect "/" "https://www.example.com/"
#ErrorDocument 403 "Sorry, direct IP access not allowed."
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
home-le-ssl.conf:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin admin#example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/html/home
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>
<VirtualHost *:443>
ServerName 111.222.33.444
ServerAlias 111.222.33.444
UseCanonicalName Off
Redirect "/" "https://www.example.com"
ErrorDocument 403 "Sorry, direct IP access not allowed."
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Answer 1

This is nothing to do with Apache configuration; an SSL certificate has to be valid for the URL you request. From the point of view of the browser, following a redirect response requires exactly the same trust in the certificate as rendering some content from the response.
From a security point of view, imagine I intercept your wi-fi signal and respond to a request for https://www.facebook.com with a redirect to https://www.my-evil-hacking-site.com (or something less obvious). If the browser follows that redirect without checking the certificate I present, I've successfully defeated the security provided by the certficate validation.
From a technical point of view, note that a TLS (formerly known as SSL) connection is negotiated before any HTTP request is made at all, and the redirect you're trying to issue is an HTTP response. There actually had to be an extension to TLS to allow the requested hostname to be transmitted as part of that negotiation, to allow for multiple virtual hosts on one IP address. If the browser rejects the certificate the server offers at this stage, it will never send an HTTP request for you to respond to.
So, as far as the browser is concerned, you need to present a certificate which is valid for https:///111.222.33.444. See: Is it possible to have SSL certificate for IP address, not domain name? to which the answer is "Yes, but it's rare". Also note that Let's Encrypt do not issue such certificates.
The reason it's rare is that there's generally no reason for anyone to try to browse to https:///111.222.33.444 in the first place. Redirects are mostly just a convenience to the user, and certificate checks are about protecting the user, not protecting the server; so just leaving it as a certificate error is generally fine.