Re: [users@httpd] Intermittent SSL failure on Tomcat port
Hi Madhan, I suppose you would have better chances with that on the Tomcat users list, however your Tomcat and Java versions are quite old (even if Tomcat in this version is still actively supported by the project, Java 7 is totally outdated in regards to TLS support). Are you using tc-native (TLS with OpenSSL) or pure Java TLS? Are any Middleboxes (that perform TLS inspection) in place? I would rather invest time to update to more recent stack (that will lead to acceptable security, IIRC Java 7 does not support TLS1.2)... Tomcat version details:- Server version: Apache Tomcat/7.0.91 Server built: Sep 13 2018 19:52:12 UTC Server number: 7.0.91.0 OS Name:Linux OS Version: 2.6.32-431.20.3.el6.x86_64 Architecture: i386 JVM Version:1.7.0_201-mockbuild_2018_10_22_02_29-b00 JVM Vendor: Oracle Corporation Best regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] HSTS verification
Hi,
On 02.07.21 09:27, @lbutlr wrote:
> When checking for https HSTS compliance on htstpreload.org I get a warning
>
>> We cannot connect to https://example.net using TLS ("Get
>> https://example.net: http: server gave HTTP response to HTTPS client").
What is in your access logs, can you identify the request and check which
virtual hosts served it? You can enable logging of the
virtual host in the access log or log to dedicated files (see
https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#formats for
a list of what is available).
> And I do not understand how this can be. The page in questions loads as https
> with a valid cert and the http query is set to redirect to https
>
>
>ServerName www.example.net
>ServerAlias foo.example.net
>ServerAlias example.net
>DocumentRoot /usr/local/www/example/
>DirectoryIndex index.html
>ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9000/usr/local/www/example/$1
>SSLEngine on
>SSLCertificateFile /usr/local/etc/dehydrated/certs/example.net/cert.pem
>SSLCertificateKeyFile
> /usr/local/etc/dehydrated/certs/example.net/privkey.pem
>SSLCertificateChainFile
> /usr/local/etc/dehydrated/certs/example.net/chain.pem
>SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
>SSLHonorCipherOrder on
>SSLCipherSuite
> ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
>#SSLUseStapling On
>Header always set Strict-Transport-Security "max-age=15638400;
> includeSubdomains;"
>Header always set X-Frame-Options DENY
>Alias /.well-known/ /usr/local/www/.well-known/
>
>
>
>ServerName www.example.net
>ServerAlias foo,example.net
>ServerAlias example.net
>ServerAlias webmail.example.net
>Redirect / https://www.example.net/
>Alias /.well-known/ /usr/local/www/.well-known/
>
>
>
I do not see anything onbviously wrong here (there is a typo on "ServerAlias
foo,example.net" though, assume this is just an example issue).
However, your TLS virtualhost is bound to a fixed IP, your plain HTTP virtual
host is bound to all available IPs on the machine.
My guess would be virtual host mismatch or a DNS specific issue (does
example.net resolve to different IPs for different resolvers?). Again
access logs may reveal some more information on that.
hth,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] SSL VHosts
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 -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. > 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 - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
