Nexus and SSL

Author, Ilkka Turunen

Author, Ilkka Turunen

For updates on articles and resources, follow @TSWAlliance on Twitter

Today’s topic comes from an interesting conversation I had with a customer about SSL certificates that can be used to secure Nexus and serve it via HTTPS. Though HTTPS should be the cornerstone in securing any web service, I thought it useful to answer small questions I’ve received here and there about SSL.

“Do I need to run Nexus over HTTPS?”

I like to think of Nexus as the parts warehouse of your organisation that contains all your building blocks and final pieces of software, and as such it’s recommended to always run Nexus over HTTPS.

With Nexus 2, though there is no need for doing so it is generally best practice to serve critical infrastructure over HTTPS.  Security itself is a good enough concern though – as Nexus 2 uses basic http authentication as the means of authentication. If you do these communications over normal http, this traffic can be intercepted with any network sniffer and credentials read!

Nexus 3 should be served over HTTPS if you intend to use it to host Docker Containers as SSL is expected by Docker. Read more in the Nexus 3 documentation:  http://books.sonatype.com/nexus-book/3.0/reference/docker.html#docker-ssl-connector

“Where should I handle SSL certificates, load Balancer or Nexus?”

The answer is entirely dependent on your use case and to a degree personal preference. Nexus can serve itself over https via the built-in jetty server.

So depends entirely on your setup and how many servers are in your estate et cetara. Configuring https is easier on a reverse proxy, and you’ll only have to do this configuration once.

“I have a signed SSL Certificate and Nexus doesn’t start? What’s up?”

For this particular problem, there are a few potential answers. The problems that can cause these kinds of issues can vary widely. Here’s how you can hunt down the right answer:

Step 1: Check the Logs for clues

  1. In Nexus 2 check wrapper.log and $SONATYPE_WORK/nexus.log for potential errors
  2. In Nexus 3 check $NEXUS_HOME/logs/nexus.log and karaf.log for potential errors

Step 2: Make sure you’ve uploaded both key and certificate into the keystore

The Jetty wrapper expects you to upload both your private key and certificate to the keystore in the PKSC12 format. Here’s a topic on how to convert keys and signed certificates: http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html#loading-keys-and-certificates-via-pkcks12

In the write up jetty.key corresponds to your private key and jetty.crt to the signed certificate chain.

Alternatively, if OpenSSL is not your cup of tea, you can also use keytool to create a private key, a csr and and import the final pksc12 to a keystore.

Step 3: If still seeing errors, check logs again

Here’s an error message you may see in rare cases:

2015-10-21 11:43:08,090+0100 WARN  [jetty-main-1] *SYSTEM org.eclipse.jetty.util.component.AbstractLifeCycle – FAILED SslContextFactory@18cbf688(/apps/nexus/nexus-3.0.0-b2015091801/etc/ssl/nexus.jks,/apps/nexus/nexus-3.0.0-b2015091801/etc/ssl/nexus.jks): java.security.UnrecoverableKeyException: Cannot recover key

java.security.UnrecoverableKeyException: Cannot recover key

This error message implies the key, certificate chain and the keystore might not all have the same password. Check that you’ve configured jetty-https.xml with the correct passwords for all sections.

If the error persist you may want to try making sure your keys and keystore have the same password.

Here’s good article on how to do this: https://confluence.atlassian.com/pages/viewpage.action?pageId=424313691

“I keep getting SSL errors about untrusted certificates with my tools. Where do I get a valid cert?”

This error occurs when you use a self-signed certificate and thus is fairly common. Using self-signed certificates in testing is okay, but should rarely be the case for production due to many reasons, such as getting tools to trust them. To get rid of it, you need to get a certificate that’s signed by a trusted authority. 90% of the time the answer is to ask your org and find out who is in charge of your certificates.

If it is custom code you’re dealing with that is used to connect to nexus, you could look into utilising Truststores. Trust stores are a way for client machines to start trusting self-signed certificates from a server. Read more here: https://docs.oracle.com/cd/E19509-01/820-3503/6nf1il6er/index.html

If you’re using nexus with something that cannot use truststore directly and if you’re just testing and need a quick certificate I do recommend trying StartSSL: https://www.startssl.com . They give out free Class 1 certificates which are enough to get things working without warnings. Another place to keep an eye out for is Let’s Encrypt, a Free CA associated with the Linux Foundation.

When loading the keys obtained from StartSSL please generate a key manually and create a csr for it on your machine and obtain signed certificates via this functionality from StartSSL. When you’re done combine the original key and signed cert into a PKCS12 CERT as described above and you’re set!

“Where can I find more reading material?”

Excellent question, my dear disembodied bolded text. Here’s some good articles  about SSL and nexus:

The following two tabs change content below.
Ilkka Turunen is a Solutions Architect at Sonatype. He has worked with companies large and small as a infrastructure consultant and as a developer. Now he aims to show how the Nexus products can benefit teams large and small. He's based in London, UK and can best be found in a coffee shop near the silicon roundabout.
Authors

Related posts

*

Top