The way I usually configure iptables or any firewall is, I do a default drop on the INPUT chain, but leave FORWARD and OUTPUT unchanged. The reasoning is as follows:
INPUT chain limits which "outer packets" are allowed to pass through the firewall. So I stop unwanted packets from coming in at all.
FORWARD chain only works on packets that are ...
I'll assume that your web server is not part of your home network.
I'll assume that for setting up your web server, you have some type of console access to your web server. I'm making this assumption because you are changing the default policy on all chains (INPUT, OUTPUT, FORWARD) of your iptables filter table to DROP which would cause any remote ...
Assuming the 'standard' config, ssl_access_log and ssl_request_log are written (in slightly different formats) for each HTTP request received on the TLS vhost. If the certificate is rejected, there is no TLS connection and it is not possible to send any HTTP request, so there is nothing to log.
Depending on the client program and TLS library it uses, it may ...
No, it is not logged on the server. This check is made on the client, there is no way to know for the server if this problem occured or not.
You can (and should) configure a default VirtualHost that catches all requests to domains not matching your "real" VirtualHosts. That way you can find out if requests to your server are made with other ...
Whilst I still haven't proven if <VirtualHost *:443> is actually working properly or not, I did still manage to solve the problem I was having by inserting my configuration for <VirtualHost *:443> outside of the tag. Maybe not a solution to my original question, but that's irrelevant now considering my ProxyPassReverse now works properly.
You're right that this represents a potential privacy concern: using SNI, the domain name is sent unencrypted.
That's why ESNI (Encrypted SNI) was proposed since by Cloudflare, who already implemented it in their CDN. At the time of this writing, browser support is close to zero, but this seems to be the future!
From what you've said your front end is hosted by Vercel, your back end by EC2. They're completely independent from a load balancing / certificate point of view.
Create a certificate for your back end server using AWS Certificate Manager (ACM). Alternately you can import an existing SSL cert into ACM, but then it won't re-issue automatically.
The second PC needs to know that my.site.com can found on the first PC; you can achieve this either using DNS or by editing the hosts file on the second PC.
Without this, the second PC has no way of knowing where to look for my.site.com.
You give the webroot on the command line when you run certbot.
--webroot -w <document root>
This should have been done the first time you obtained the certificates but if you used a different method to do so, then it would not have been saved.
You have to open port 443 in your AWS security group.
You have to explain what "not working mean".
Server not listening?
Wrong site shown?
Browser complains about certificates?
(I just deleted an incorrect answer)
You have listed ServerName step9productions.com:443 in ssl.conf and ServerName step9productions.com in httpd.conf That ...
Just find where the "Listen 443" is and paste above NameVirtualHost *:443
In my case was in ssl.conf file
If you restart the http server and you are getting the message "Listen 443 is deprecated" delete "Listen 443" and leave only NameVirtualHost *:443
The OP chose not to post an answer, but did say that they solved the problem:
The problem was that there was were some strange domains added in the search part of /etc/resolve.conf on the host. And when I was trying to make a https request I have been redirected by DNS to some other server responding with plain http.
Correcting the DNS settings solved the ...