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>
Related
I'm setting up a Tomcat server behind an Apache proxy, everything is working fine except for the forward proxy when dealing with a remote server with a self-signed certificate. I can access other HTTPS sites, but not ones with self-signed certs. I've already added the CA using SSLProxyCACertificateFile, but it still doesn't work.
In the error log, I get "AH00898: Connect to remote machine blocked returned by server_hostname".
Apache 2.4.54 on Debian 11
I can wget the URL (Once I added the CA to Debian). I can also access the URL if I allow Tomcat to bypass the proxy (When the CA is in the Java key store). But I need all the traffic to go through the proxy.
<VirtualHost 10.10.10.6:8082>
ProxyRequests On
ProxyVia On
<Proxy "*">
Require ip 10.10.10
</Proxy>
ErrorLog ${APACHE_LOG_DIR}/error_forward_proxy_secure.log
CustomLog ${APACHE_LOG_DIR}/access_forward_proxy_secure.log combined
SSLProxyCACertificateFile /var/ssl/trusted_ca.crt
</VirtualHost>
What am I doing wrong?
Apache server is proxying requests to express server running on 9999
<VirtualHost *:443>
ServerName api.aonesalons.com
SSLEngine on
SSLCertificateFile /home/ec2-user/aonesalons.com.pem
SSLCertificateKeyFile /home/ec2-user/aonesalons.com.key
# <Proxy *>
# Order allow,deny
# Allow from all
# </Proxy>
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://localhost:9999/
ProxyPassReverse / http://localhost:9999/
</VirtualHost>
If I hit, api.aonesalons.com in browser, my request goes to the server.
from my application frontend, that is also served over https by apache, when any of the api url's are called,
it always returns
ERR_FAILED or ERR_INSECURE_CONNECTION
Edit:
In browser console in security tab, the certificate is valid totally. I have tried proxying requests to the https version of the express server as well but no difference. It started happening after moving to https.
As soon I start to use Cloudflare as a proxy for api.aonesalons.com, api.aonesalons.com returns my client end application and doesn't hit my API's. I am using apache to proxy api.aonesalons.com to 9999 server and *.aonesalons.com to client folder with static application content
From the SSLLabs report for api.aonesalons.com:
Trusted - No - NOT TRUSTED
A closer look at the certificate shows:
Subject - CloudFlare Origin Certificate
Issuer - CloudFlare, Inc.
This is not a certificate intended for direct access by the public. It is trusted only by Clouldflare itself and is intended to secure the path between the Cloudflare CDN and the server protected by this CDN, see Introducing CloudFlare Origin CA.
In browser console, in security tab, certificate is valid totally.
I don't know what you did to you browser but maybe you explicitly trusted the Cloudflare CA. When visiting the site with a browser I get the expected warning:
NET::ERR_CERT_AUTHORITY_INVALID
My guess is that you've tried to protect your site with the Cloudflare CDN but failed to adjust the DNS settings properly in order to let Cloudflare manage the relevant parts of your DNS.
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
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.