Can a signed certificate be used without importing explicitly?

Question

I've read a lot of articles regarding the import of a cert, but I am still unclear on a couple things.

When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?

I can install a client cert manually, but there is an expiration date. So I'll need to manage the expiration dates of all client installed certs on our application server, and take an outage to update each one. It feels like there should be a better way. Shouldn't the application automatically accept a valid signed cert? [In this case, it is signed by VeriSign]

We are getting an exception currently when trying to access an https url from the application without explicitly installing the cert. The API proxy library is swallowing the internal exception, so I dont know the details.

If the cert should be accepted automatically, then there may be a different issue here...

Answer 1

Can a signed certificate be used without importing explicitly?

Yes, it does not need to be installed prior to use. In fact, if you know in advance of what to expect, then you can include that information into the application. That has an added benefit of improving the application's security posture.

To avoid importing the certificate, use a custom X509TrustManager and override checkServerTrusted. In checkServerTrusted, ensure the server's public key is expected (i.e., pin the server's certificate or public key); or verify the server's certificate is valid (i.e., is within validity and forms a chain to your trusted root).

---

When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?

In the case of client certificates, the server advertises the issuer whom it relies upon to issue client certificates. So the server will need to know the trust point for issuing client certifcates for authenticating clients.

---

In this case, it is signed by VeriSign

This could be really bad. In this case, you will trust all of your clients signed under the Verisign PKI, and all of Verisign's other clients signed under the Verisign PKI.

In this case, it would probably be better to avoid public CAs and run your own PKI (i.e., be your own CA). In this case, pick up a copy of Network Security with OpenSSL. The book will show you how to accomplish the customary tasks using both the openssl command and programmatically.