Resummarising my question:
I have got a Apache web server fronting the Jboss.
below is the ssl part of the Httpd conf
ProxyRequests Off
SSLProxyEngine on
SSLCertificateFile
/FinMgmt/deploy/https/certs/webserver/fm.insurance.co.uk_a_cert.pem
SSLCertificateKeyFile
/FinMgmt/deploy/https/certs/webserver/fm.insurance.co.uk_a_key.pem
SSLCACertificateFile
/FinMgmt/deploy/https/certs/fm.insurance.co.uk_CA_cert.pem
SSLVerifyClient optional_no_ca
SSLOptions +ExportCertData
ProxyPass /webapp1 https://fm.insurance.co.uk:8443/webapp1
ProxyPassReverse /webapp1 https://fm.insurance.co.uk:8443/webapp1
ProxyPass /webapp2 https://fm.insurance.co.uk:8443/webapp2
ProxyPassReverse /webapp2 https://fm.insurance.co.uk:8443/webapp2
Below is the ssl part from jboss server.xml:
<!-- SSL/TLS Connector configuration using the admin devl guide keystore clientAuth=false -->
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="500" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="${jboss.server.home.dir}/conf/server.keystore"
keystorePass="glamdev"
truststoreFile="${jboss.server.home.dir}/conf/server.truststore"
truststorePass="passwd"/>
As per my understanding, Apache is configured to use 2 way mutual authentication with SSLVerifyClient optional_no_ca meaning that client may or maynot provide the certificate.
Now jboss is configured to one way SSL authentication.
Now what I understand is ,when browser send request apache,apache will respond with the certificate and browser will try to authenticate using its root CA or throw an exception asking user to store it.
And when apache will route request to jboss,here apache will act as client and jboss as SSL server,jboss will send its certificate from keystore which will be verified by the Apache using SSLCACertificateFile directive
And if jboss has to redirect to itself ,it will have to go through the reverse proxy as we have set proxyPassReverse.In that case jboss will act as SSL client and Apache http as SSL server and Apache will will send its certificate which jboss verify using the CA certificate in trustore.
Am I right in interpreting the config files?
Also I dont exactly understand the use of optional_no_ca in SSLVerifyClient.Will apache request the certificate from browser or not or it depends upon the browser ?
Actually I have inherited this application with no documentation whatsover and I am trying hard to make some sense out of it.
I'm assuming that what you're after is to use client-certificate authentication in your JBoss application, to authenticate browsers (not Apache Httpd as a client to JBoss).
If you want to have Apache Httpd as a reverse proxy in front of you JBoss container, you need to configure Apache Httpd to request and handle client-certificate authentication. In particular, you should use its SSLCA* and SSLVerifyClient directives, part of mod_ssl.
Whether you configure SSL/TLS between Apache Httpd and your JBoss worker node is independent. It's often unnecessary if you're on a trusted network at that point. If you do want SSL/TLS there, use Apache Httpd's SSLProxy* directives to configure which CA to trust. This being said, doing so will certainly create more confusion within your application, since there would be an ambiguity as to where the client-certificate information comes from: either a real-client certificate authentication at the JBoss container level, or a relayed certificate, as handled by Apache Httpd.
Indeed, you'll need to pass on the client-certificate information to your container for further information, as described in this answer.
If instead, what you're after is client-certificate authentication between Apache Httpd and JBoss, where you need this connection to be secured with SSL/TLS and to make sure if comes from the reverse proxy (which would present its certificate), you should be able to to this using SSLProxyMachineCertificateFile available in Apache Httpd 2.4. (This configuration is certainly unusual.)
EDIT: (Following changes to the question.)
As per my understanding, Apache is configured to use 2 way mutual
authentication with SSLVerifyClient optional_no_ca meaning that client
may or maynot provide the certificate.
SSLVerifyClient optional_no_ca means that Apache Httpd will only check that the client has the private key for the certificate it presents: it won't verify that the certificate is trusted (making SSLCACertificateFile useless). If you want presentation of the certificate to be optional, but still verify it against your PKI, use SSLVerifyClient optional (with SSLCACertificateFile).
Now jboss is configured to one way SSL authentication. Now what I
understand is ,when browser send request apache,apache will respond
with the certificate and browser will try to authenticate using its
root CA or throw an exception asking user to store it.
Yes, and the connection between the browser and Apache Httpd has nothing to do with JBoss.
And when apache will route request to jboss,here apache will act as
client and jboss as SSL server,jboss will send its certificate from
keystore which will be verified by the Apache using
SSLCACertificateFile directive
No, it's SSLProxyCACertificateFile (or ...Path)
And if jboss has to redirect to itself ,it will have to go through the
reverse proxy as we have set proxyPassReverse.In that case jboss will
act as SSL client and Apache http as SSL server and Apache will will
send its certificate which jboss verify using the CA certificate in
trustore. Am I right in interpreting the config files?
I'm not sure under which circumstances JBoss would "redirect to itself" (or what you mean by this). There's nothing to suggest JBoss has a role as a client here. This is not what ProxyPassReverse is for.
Also I dont exactly understand the use of optional_no_ca in
SSLVerifyClient.Will apache request the certificate from browser or
not or it depends upon the browser ?
When you set SSLVerifyClient to optional, optional_no_ca or require, the server will request a certificate. With require, it will terminate the connection if the client doesn't send one (that it trusts).
As your configuration stands, there's nothing to suggest that the client-certificate is conveyed to the JBoss container. It's not verified in any way at the Apache Httpd level (anyone with a self-signed client-certificate could connect here). You could in principle use optional_no_ca, let any certificate through and only verify them once they arrive to the Java container, but you'd certainly need some extra custom code to do so in your JBoss application. You would also need to convey the certificate itself somehow (e.g. via mod_header and a custom header or more directly using mod_proxy_ajp. It would also be harder to break the connection to make the client try another certificate if the one it presented initially was incorrect.
Related
The setup I am working with involves an Apache server acting as a proxy to a tomcat server which serves several web applications. I have enabled mutual TLS on apache and I can successfully connect to one of my tomcat web applications and verify the client certificate. However, I want to take this one step further... At the moment in my ssl.conf I have a default HTTPS VirtualHost configuration which looks like this:
<VirtualHost *:443>
....
SSLEngine on
SSLCertificateFile /path/to/www_yoursite_com.crt
....
#other SSL options...
</VirtualHost>
In my modproxy.conf I have a configuration as follows:
ProxyPass /webApp1 https://localhost:1234/webApp1
ProxyPassReverse /webApp1 https://localhost:1234/webApp1
ProxyPass /webApp2 https://localhost:1234/webApp2
ProxyPassReverse /webApp2 https://localhost:1234/webApp2
where 1234 is the https port configured on a connector element on tomcat's server.xml file.
Let's assume that I only want mTLS for webApp1, the problem with this configuration is that I need a client cert on my browser even if I am accessing webApp2 so in other words I want to enable mTLS only for one web application. Even better, I would like to enable mTLS for a specific URL within my web application (is this even possible??), so for example I want mTLS required when someone hits https://myserver.com/webApp1/test/mtlsEndpoint but not on https://myserver.com/webApp1/test/otherEndpoint.
Is it possible to achieve this with another VirtualHost config for SSL on my ssl.conf ? I am going to test this tomorrow (trying to achieve this with another VirtualHost config that will proxy mTLS to my webApp1) but thought I should ask here as well to avoid trial and error and reinventing the wheel maybe this is easier than I am thinking ?
Yes, you just need separate SSL directives for webApp1 and webApp2. SSL directives can be configured in Apache right down to the directory level.
I'm trying to establish a reverse proxy setup with apache that securely supports SSL all the way through:
Client <--> Proxy # somehostname.com <--> Server # 123.45.67.89
Note that my proxy server has a hostname, but the remote server does not. The SSL setup between clients and the proxy works fine with a letsencrypt setup. However, I am struggling to secure the connection between the proxy and the remote server.
Because the remote server doesn't have a hostname, and letsencrypt doesn't issue certificates for IPs only, my idea was to generate a self-signed certificate and copy the certificate over to the proxy for it to only trust that one. Unfortunately I don't know how.
If I just disable these certificate checks, the connection works, as the proxy just trusts every certificate:
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
While encryption will work fine, to my understanding authenticity is compromised and I am subject to MitM attacks during the handshake. This is not ideal.
Instead, I've instructed Apache to trust my self-signed certificate with
SSLProxyCACertificateFile /path/to/cert.pem
and then tried to enforce a valid certificate with
SSLProxyVerify require
but despite me explicitly listing the certificate, and the documentation of SSLProxyCACertificateFile saying "These are used for Remote Server Authentication", it seems to not trust it.
Is there a way to make sure the connection between the proxy and remote server is safe, for example by enforcing Apache to always connect to the proxy using that specific certificate?
Turns out adding certificates via SSLProxyCACertificateFile does not skip name checks, which makes total sense. So in order for custom certificates to work, they still need to be issued to the correct name, or in my case, the IP. After I made a new certificate issued to that IP, my configuration works now. Here are the relevant parts:
<VirtualHost *:443>
ServerName somehostname.com
SSLProxyEngine On
SSLProxyVerify require
SSLProxyCACertificateFile /path/to/custom_cert.pem
SSLProxyCheckPeerCN on # or omit, default is on
SSLProxyCheckPeerName on # same
ProxyPass / https://123.45.67.89/
ProxyPassReverse / https://123.45.67.89/
</VirtualHost>
I edited '/etc/apache-sites-enabled/default-ssl.conf' to include the following:
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/mydomain.com.crt
SSLCertificateKeyFile /etc/apache2/ssl/mydomain.com.key
SSLCertificateChainFile /etc/apache2/ssl/mydomain.com.ca-bundle
The files exist and contain the relevant blocks from my Rapidssl. SSL is enabled via a2enmod ssl, have also checked port is open and checked error log.
The apache error log is clear and http is accessible.
When I visit the site I get this message in Chrome:
SSL connection error
ERRSSLPROTOCOL_ERROR
Hide details
Unable to make a secure connection to the server. This may be a problem with the server or it may be requiring a client authentication certificate that you don't have.
To me it seems to be pointing to the CA Bundle being not seen?
I've configured a Reverse Proxy with Apache, that proxy request to Tomcat Servers.
I've not found if it is possible to handle SSLCertificateFile on proxy itself (in order to avoid the configuration of certificate on each internal server) and instead configure SSLCACertificateFile on each proxied server, configuring the proxy to forward Client Certificate handling to the specific server.
Does someone have some tips for me?
Thank you!
You can't do that. The handshake is a unitary thing. You are terminating SSL at the HTTPD, which means it has to both provide its own certificate and CA certificate. What you are asking doesn't make sense.
The document is not clear. How to install certificate and etc in localhost?
force-ssl
This package causes Meteor to redirect insecure connections (HTTP) to a secure URL (HTTPS). Use this package to ensure that communication to the server is always encrypted to protect users from active spoofing attacks.
To simplify development, unencrypted connections from localhost are always accepted over HTTP.
Application bundles (meteor bundle) do not include an HTTPS server or certificate. A proxy server that terminates SSL in front of a Meteor bundle must set the standard x-forwarded-proto header for the force-ssl package to work.
Applications deployed to meteor.com subdomains with meteor deploy are automatically served via HTTPS using Meteor's certificate.
I've slogged through setting up an Apache reverse proxy that terminates SSL in front of Meteor, and wanted to document that here as well.
I added the following to the config file for the SSL virtual host:
<VirtualHost _default_:443>
ServerName server.domain.com
## SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
## Proxy to port 3000 for Meteor apps
SSLProxyEngine On
ProxyRequests Off # Disable forward proxying
ProxyPass / http://localhost:3000
ProxyPassReverse / http://localhost:3000
## Your other SSL config directives such as certificates, etc.
</VirtualHost>
You do not need to install certificates on localhost. As it says "To simplify development, unencrypted connections from localhost are always accepted over HTTP.", which means that you can develop and test the application without using SSL and without installing certificates. Just run you application and access it with http://localhost:3000 as usual.
If you are talking about installing certificates for publicly facing applications it is probably best to use a reverse proxy server such as nginx and install the certificates for that server. http://wiki.nginx.org/HttpProxyModule