On Fri, Feb 16, 2018 at 2:11 PM, Christopher Schultz
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 2/14/18 3:34 PM, Chris Cheshire wrote:
>> On Wed, Feb 14, 2018 at 12:30 PM, Mark Thomas <ma...@apache.org>
>>> On 14/02/18 17:17, Chris Cheshire wrote:
>>>> I am trying to set up my webapp to connect to an external
>>>> database via ssl. The database uses a self-signed certificate.
>>>> I have created a keystore with the self-signed CA and the
>>>> client key & cert. This keystore is configured via JAVA_OPTS in
>>>> \ -Djavax.net.ssl.keyStorePassword=password \
>>>> -Djavax.net.ssl.trustStore=$CATALINA_BASE/conf/mysql.jks \
>>>> This allows me to connect to the database without a problem.
>>>> However now I cannot connect to any external web service
>>>> because their certs will no longer validate.
>>>> How do I configure tomcat such that the default cacerts is used
>>>> in addition to my self-signed certificates without importing
>>>> those into the default keystore (which is a Bad Idea™)?
>>> This is nothing to do with Tomcat. Tomcat plays no role in
>>> out-going TLS connections.
>>> The short answer is rather than using system properties, you
>>> should set the keystore and truststore programmatically so they
>>> apply just to the database connections rather than globally.
>> So after a bit of digging [1,2] I found that this is achieved by
>> adding the following parameters to the mysql jdbc url in the
>> resource definition:
>> Note that  has a couple of errors. A) it specifies
>> clientCertificateKeyStore[Url|Password] in lieu of trustStore
>> system property, that should be
>> trustCertificateKeyStore[Url|Password] B) it specifies specifies
>> the urls in the form file:path_to_truststore_file, that is also
>> incorrect it should be file://path_to_truststore_file (which will
>> give a triple slash if an absolute path is used)
> - -ssl.html
> It might depend upon the version of Connector/J you are using. For
> example, I have this in my connection URL:
> Only a single leading / for an absolute path in my case, and it works
> as expected.
> The use of file:// was a historical mistake web browser users made,
> thinking that // was necessary between the protocol and anything after
> it. It was never the case, and any software requiring a URL like
> file:/// should be considered broken.
> - -chris
So I went back to retest everything to make sure I wasn't going crazy,
and it turns out that I actually am. It really is working as expected
without the double slash (and with). I guess I went crosseyed looking
at the error logs after so many attempts trying to get this working
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org