Apache not Forwarding Client x509 Certificate to Tomcat via mod_proxy
Apache is generating a brand new SSL session for the connection to the backend tomcat server, so the client certificate data isn't passed; the system with the cert isn't the client anymore.
If you're ok with an unencrypted connection between Apache and the Tomcat device, then using an AJP proxy connection (ProxyPass / ajp://x.x.x.x:8009/
) instead of SSL, and adding an SSLOptions +ExportCertData
directive in Apache, should pass the certificate data to Tomcat. There more info on passing certificate information here.
Related videos on Youtube
hooknc
Basic to advanced Java programmer. Career emphasis on web development, component design, and human computer interaction/usability.
Updated on September 17, 2022Comments
-
hooknc over 1 year
I am having difficulties getting a client x509 certificate to be forwarded to Tomcat from Apache using mod_proxy.
From observations and reading a few logs it does seem as though the client x509 certificate is being accepted by Apache. But, when Apache makes an SSL request to Tomcat (which has clientAuth="want"), it doesn't look like the client x509 certificate is passed during the ssl handshake.
Is there a reasonable way to see what Apache is doing with the client x509 certificate during its handshake with Tomcat?
Here is the environment I'm working with: Apache/2.2.3 Tomcat/6.0.29 Java/6.0_23 OpenSSL 0.9.8e
Here is my Apache VirtualHost SSL config:
<VirtualHost xxx.xxx.xxx.xxx:443> ServerName xxx ServerAlias xxx SSLEngine On SSLProxyEngine on ProxyRequests Off ProxyPreserveHost On ErrorLog logs/ssl_error_log TransferLog logs/ssl_access_log LogLevel debug SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile /usr/local/certificates/xxx.crt SSLCertificateKeyFile /usr/local/certificates/xxx.key SSLCertificateChainFile /usr/local/certificates/xxx.crt SSLVerifyClient optional_no_ca SSLOptions +ExportCertData CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" <Proxy *> AddDefaultCharset Off Order deny,allow Allow from all </Proxy> ProxyPass / https://xxx.xxx.xxx.xxx:8443/ ProxyPassReverse / https://xxx.xxx.xxx.xxx:8443/ </VirtualHost>
Then here is my Tomcat SSL Connector:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" address="xxx.xxx.xxx.xxx" maxThreads="150" scheme="https" secure="true" keystoreFile="/usr/local/certificates/xxx.jks" keypass="xxx_pwd" clientAuth="want" sslProtocol="TLSv1" proxyName="xxx.xxx.xxx.xxx" proxyPort="443" />
Could there possibly be issues with SSL Renegotiation?
Could there be problems with the Truststore in our Tomcat instance? (We are using a non-standard Truststore that has partner organization CAs.)
Is there better logging for what is happening internally with Apache for SSL? Like what is happening to the client cert or why it isn't forwarding the certificate when tomcats asks for one?
Any reasonable assistance would be greatly appreciated.
Thank you for your time.
-
hooknc about 13 yearsInteresting. Would you recommend mod_jk or mod_proxy_ajp for using the ajp connector? Thank you for your informative response.
-
ravi yarlagadda about 13 years@hooknc Use mod_proxy_ajp if it will fill your needs; it's part of the standard modules so it's less likely to give you issues on upgrades - it was created as basically a replacement for mod_jk.
-
hooknc about 13 yearsFantastic. Looking into that module now. Thank you again.
-
hooknc about 13 yearsSorry, but one more question. Will tomcat be able to differentiate the difference between http and https requests using the ajp connector? Because of course, we do require https for some connections and not for others and we are currently enforcing security programmatically via spring security.
-
hooknc about 13 yearsActually check that last comment. I didn't fully read that nice link you posted to tomcats ajp explanation. My guess is that tomcat will be able to differentiate between http and https requests.
-
hooknc about 13 yearsThis solution seems to be working perfectly. The client certificate is being forwarded to tomcat and the http vs https concern I had in a previous comment is working the way I hoped. Thank you again!