# HTTPS Jetty error

Figuring out an obscure jetty error in the adapter

Recently our integrations team have been deploying some HTTPS enabled adapters to service some customers who wanted to POST requests into our hub infrastructure. Interestingly they encountered a problem which they came to me with. Basically, during testing with one particular customer they found that there was excessive continuous logging which ended up raising a red flag via some our file system monitoring processes (I did have a little chuckle at their work-around initially).

The error message was a continual stack trace along these lines being logged to the adapter log file, the adapter was still working and happily processing requests from other partners:

They verified the problem running on a local adapter, and it didn’t take me too long to figure out what the problem was. Basically they were using a self-signed certificate and what our customer had done was to try and connect to the adapter using his browser; and once he’d done that it started generating all the spurious logging. The root cause is the termination of the SSL negotiation while the browser comes up with the This connection is untrusted because we can’t verify the sites identity; do you want to continue? page. Easy to fix once you know what the problem is.

There are two solutions to the problem, and we used both in the end.

• First and best, use a properly signed certificate from Thawte / Verisign / whoever, so long as it’s not DigiNotar.
• Once we imported the self-signed certificate into Firefox, the stack trace logging went away
• Second and most expedient, change log4j.xml to simply not output the logging because it’s not terribly relevant and can be safely ignored (it’s logging @ DEBUG level, and it’s information that you don’t care about).

## Actually using a real certificate

Anyway, this led them down another twisty rabbit warren of confusion. It turns out that our standard certificate was created using openssl for our apache instances (i.e. using openssl genrsa, and all that business) which meant that the private key and certificate were stored in separate files rather than in a single PKCS12 file. This did present some trouble when trying to use something like keytool or portecle to try and generate a keystore for use by jetty. This isn’t rocket science; and google can give you the answers; the top 2 links basically are the links you need (stackoverflow, and agentbob.info)

We ended up going with the instructions from http://www.agentbob.info/agentbob/79-AB.html which can be basically condensed down to the following steps:

• Create DER encoded files of all PEM files.
• Concatenate all the certificates into a single file, creating a certificate chain (this will depend on whether or not your CA provider gives you intermediate certificates which you need to configure using SSLCertificateChainFile)
• Modify ImportKey.java slightly to resolve a minor issue1
• Change line 147 from certs = (Certificate[])c.toArray(); to certs = (Certificate[])c.toArray(new Certificate[0]);
• Compile and execute ImportKey.java

Afterwards you can use keytool/portecle to modify the keystore alias/passwords and whatnot as desired and start using them in jetty.

1. This is so you don’t have to go through the comments… ↩︎

Powered by Hydejack v6.6.1