Hi Chris,

On Sat, Feb 24, 2018 at 7:52 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Hash: SHA256
> Igor,
> On 2/23/18 4:45 AM, Igor Cicimov wrote:
> > Hi all,
> >
> > I have the following setup in the tomcat default file on
> > Ubunntu-14.04:
> >
> > -Djavax.net.ssl.keyStore=/opt/encompass/keystore/keystore.jks"
> > -Djavax.net.ssl.trustStore=/opt/encompass/keystore/truststore.jks"
> >
> > The keystore.jks holds dozen of SSL keys our app uses to
> > authenticate to various web services. One of these certificates
> > expired and I used openssl to create new private key (key.pem) and
> > CSR, that the other side signed and sent back (cert.pem). Then I
> > concatenated the certificate and the private key into single file:
> >
> > $ cat cert.pem key.pem > cert2.pem
> >
> > and imported the file into the existing keystore using keytool:
> >
> > $ keytool -delete -alias client-cert -keystore keystore.jks
> > -storepass xxxx $ keytool -import -alias client-cert -file
> > cert2.pem -keystore keystore.jks -storepass xxxx
> >
> > The signing root CA and the intermediate certificate already exist
> > in the truststore.jks keystore.
> >
> > Does this procedure sound sane? Is there a better (or maybe proper)
> > way of doing it?
> Are you just sanity-checking your process for importing certs into a
> JKS bundle?

I'm just sanity-checking the process in terms of keystore functionality and
any possible issues for the JVM using and finding the cert and the key in
the store.

The reason being after importing the new cert our access does not work any
more and the issuer has a limited (as they say, *sigh*) troubleshooting
capability on their side. Not sure how is that possible having in mind that
they have designed and are in control of the authentication (ssl client
certs) and authorization (username/password) system (Tivoli Axis2 app if
that matters). Building something and then not being able to tell clients
if their access is denied due to bad/missing certificate or bad/missing
credentials is just unbelievable. They even claim they can't even see our
side connecting at all to their web service although in our logs I can see:

Invalid Content-Type:text/html. Is this an error message instead of a SOAP

response coming back but as html error message instead of SOAP response.

> Does the process result in the items you expected to be in the keystore?

>From what I can see all the bits are there. I have enabled the java ssl
debugging and can see the cert being loaded on startup and exchanged during
SSL handshake and no errors can be seen in the process, like the usual PKIX
error when matching cert can not be found etc.

Any ideas what can be possibly wrong?

> I'd personally be very paranoid if the JKS file was the only place all
> of those key/cert pairs were stored, because of my (bad) experience
> using JKS keystores in the past. Thankfully, Oracle is finally
> deprecating them and making the default keystore type PKCS12 in the
> future. JKS (and it's surprisingly extant cousin, JSEKS) never should
> have existed.
Yeah I saw some warning messages with the latest Oracle jdk-1.8_161 about
JKS being deprecated in favour of PKCS12 when I use keytool on the servers.
I never saw those before at least not for jdk-1.7 for sure.

> - -chris


Reply via email to