Trust Cert File Location

[Steven Feinstein <st...@yahoo.com.INVALID>]

Hi,

I am using Tomcat 8.0.32 running on Windows 2012 R2 as a Service.

My application is running under https port 8443
Part of my application opens an HttpsURLConnection back to the same app
A cert was created for each server and the keystore file updated with the information.

On my dev server, this all works OK.  On my test server, it is failing with trustAnchors parameter cannot be empty.  I understand this error to basically mean I am not accessing my trustStore file.

Our server.xml file does list the keyStore location for port 8443.  It does not contain a trustStore entry (not even sure if that would work as I did not try it).

The first thing I tried was creating setEnv.bat with java options for the keystore and trustore locations and passwords.  This did not work which I figured out is because we are running as a service, so it never gets called.

The next thing i tried was running tomcat8w //ES/Tomcat8.  This opened up a window to make entries in a Java tab which allowed me to enter the locations.  I know the keystore was picked up because I mistyped it and hung my app.  Fixing the spelling and the app stopped hanging.  But I still kept getting the error.

I started looking at any difference I could find between the servers.  That is when I noticed that the person who installed the cert on the dev server placed it in e:\tomcat8\cert.  The person who installed it on the test server placed it in e:\tomcat8\cert3.

Next, I printed the values of System.getProperty("javax.net.ssl.trustStore") and System.getProperty("javax.net.ssl.keyStore").
This resulted in null for the keystore and e:/tomcat8/cert/mystore for the trustStore.

I went back to tomcat8w and re-entered the values on the test machine:
keystore was now e:/tomcat8/cert3/mystore  while trustStore still showed e:/tomcat8/cert/mystore

I can't figure out where the trustStore value is coming from.  I searched using a grep tool for mystore and it's only location is in server.xml in the keystore entry for 8443 and is correct at e:/tomcat8/cert3/mystore.

What I have currently done is removed the entries from tomcat8w (which is really the registry), renamed cert3 to cert, modified server.xml to also point to cert.  Now everything runs fine.

I can live with this, but I'd like to know why the trustStore value keeps showing e:/tomcat8/cert and would never show e:/tomcat8/cert3.  Why did it always assume the cert location?  I can't find any entry on my server nor can I even find mystore without a path (assuming maybe Tomact prepends a default if found without a path).

I'd like to klnow how to change the path in case it is ever needed at a later date - if it is possible at all.

Does anyone know how Tomcat comes up with the trustStore location?

Thanks,
Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Trust Cert File Location

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Steven,

On 10/12/18 14:47, Steven Feinstein wrote:
> Hi,
> 
> I am using Tomcat 8.0.32 running on Windows 2012 R2 as a Service.
> 
> My application is running under https port 8443 Part of my 
> application opens an HttpsURLConnection back to the same app A
> cert was created for each server and the keystore file updated with
> the information.

It's worth stopping here to note that Tomcat's keystore and truststore
configuration only effect the connections coming into Tomcat.over
whatever <Connector> is being configured with those stores.

That may help you understand things from here on out...

> On my dev server, this all works OK.  On my test server, it is 
> failing with trustAnchors parameter cannot be empty.  I understand 
> this error to basically mean I am not accessing my trustStore
> file.
> 
> Our server.xml file does list the keyStore location for port 8443. 
> It does not contain a trustStore entry (not even sure if that
> would work as I did not try it).

Trust stores are used by an endpoint to determine whether the other
end of the connection is trusted. For most servers, the client is
irrelevant: the server is willing to accept requests from anyone. If
your clients need client-certificates, you'd have to specify a value
for the truststore.

For *clients* (those processes making connections to remote web
servers), a trust store needs to include either the certificate of the
server being contacted OR a certificate that was used to sign any of
the certificates that the server presents. Often, you will be
contacting a server that has a cert from a well-known CA and the
built-in truststore will be sufficient. If you have a self-signed cert
on the server or use a little-known CA, then you will have to specify
your own trust store and put the appropriate certificate in that store.

> The first thing I tried was creating setEnv.bat with java options
> for the keystore and trustore locations and passwords.  This did
> not work which I figured out is because we are running as a
> service, so it never gets called.

This should actually work.

> The next thing i tried was running tomcat8w //ES/Tomcat8.

... unless you are running as a Windows Service. The .BAT files are
ignored for the service. Instead, you should run tomcat8w //ES/Tomcat8 :
)

> This opened up a window to make entries in a Java tab which
> allowed me to enter the locations.  I know the keystore was picked
> up because I mistyped it and hung my app.  Fixing the spelling and
> the app stopped hanging.  But I still kept getting the error.

Good. Well, not good but at least SOMETHING is happening. Can you post
exactly that you typed, and where?

> I started looking at any difference I could find between the
> servers. That is when I noticed that the person who installed the
> cert on the dev server placed it in e:\tomcat8\cert.  The person
> who installed it on the test server placed it in e:\tomcat8\cert3.
> 
> Next, I printed the values of 
> System.getProperty("javax.net.ssl.trustStore") and 
> System.getProperty("javax.net.ssl.keyStore"). This resulted in
> null for the keystore and e:/tomcat8/cert/mystore for the
> trustStore.

No filename extension? That's uncommon, but not necessarily a problem.

> I went back to tomcat8w and re-entered the values on the test 
> machine: keystore was now e:/tomcat8/cert3/mystore  while
> trustStore still showed e:/tomcat8/cert/mystore
> 
> I can't figure out where the trustStore value is coming from.  I 
> searched using a grep tool for mystore and it's only location is
> in server.xml in the keystore entry for 8443 and is correct at 
> e:/tomcat8/cert3/mystore.

That won't affect outgoing connections. Also, the keystore won't be
used for making outgoing connections unless the remote server requires
client-certificate authentication. Does it?

> What I have currently done is removed the entries from tomcat8w 
> (which is really the registry), renamed cert3 to cert, modified 
> server.xml to also point to cert.  Now everything runs fine.
> 
> I can live with this, but I'd like to know why the trustStore
> value keeps showing e:/tomcat8/cert and would never show
> e:/tomcat8/cert3.

You'd have to look around in the configuration utility. There are many
boxes, but it should be there somewhere.

> Why did it always assume the cert location?  I can't find any
> entry on my server nor can I even find mystore without a path
> (assuming maybe Tomact prepends a default if found without a
> path).
> 
> I'd like to klnow how to change the path in case it is ever needed
> at a later date - if it is possible at all.
> 
> Does anyone know how Tomcat comes up with the trustStore location?

Tomcat itself sets none of this. If it's in the system properties,
it's because of some explicit configuration *somewhere*.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvA/QwACgkQHPApP6U8
pFiYPQ//QvRwwZTPetP2CiXoaexl8PfCUyxUU4OpxHY8CTqWDIcLbllHbCULU5ls
xbhyS7K1qyfemzRK7BLt6ToS8gjgM9J+UgoSmv70ot3FIKZL+/g6E6ojHc1ao9sn
33TyxPMNct61vSgvweP3V9Qjg6LzeauzicHP+e0E5raR8159DZ8rccDf5haMuura
+84VpQwVYn6F+ajBtIMerNHi/unFsmOyRwooSzMri5KnKmDhSqs5A0PsCMiRWTB9
qKmCvbHoGxSCYb0ePS0cg8ivzesjgKDl9oF4dY+LFfV9t2+j7YhNebMhzQrLKp8L
NzpE3pFuuorWruc1JE9OqybWlILqLDlf2KDE/NaSKvJNZIwYYjcLH0iO4919wIHu
FnpcC410/gkPodJC11hXftDtgMt0KIQ84yWppqd/n0l4qfwdnq0Lfx7/R0Xv5ztY
nvuiJYoozL1hb17ia3oBOqFW8G+7ykuzfrKOq2rwyl2j0pfRc20QAYmebiuMuiDh
gQo46DaNImYSRJGy4Rl7S0BXVc2E3YcASOlwujySWu3e8YjI4s3lJqZ2q44iq95t
DE1jFalYZVMEO5qwMiYey8uBl/JsUSVti23BWNKa269pfBujXL7gU7YToJdXZ1//
LKJaP26KbU8hFjhABceS4tZEcfoadtBwvyfBU+hZw6Eo/wlGGyc=
=X3a8
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org