PGP: How To Use The SKS Keyserver Pool over HTTPS

S/Notify provides the extremely useful option to automatically retrieve PGP public keys from a keyserver. By doing so, all email notifications will be encrypted without the Jira or Confluence users having to do anything at all to allow for it. That's perfect! But which PGP keyserver should we use?

Keyservers vs. Keyserver Pools

There are a lot of PGP keyserver on the web that can be used. However, some of them are less reliable than others. Requests sometimes take too long so they timeout, or they fail completely, because the server is temporarily down for whatever reason.

The SKS keyserver pool is an attempt to provide a better uptime, taking into account that many PGP keyserver are provided without any guaranty regarding their uptime. If you use the url pool.sks-keyservers.net in the Golbal Key Management of S/Notify, that server will act similar (but not quite like) to a proxy. Requests will be forwarded to a specific keyserver in the pool which then sends the response back to you. 

To learn more about the available server pools, check out the overview of the pools at sks-keyservers.net.

Now, let's look another important recommendation when using PGP keyservers.

Why You Should Use HTTPS

Another recommendation regarding the usage of PGP keyservers is to use them over HTTPS. By the way, HKPS is just the same as HTTPS. But should HTTPS be a must?

If you request PGP keys from a keyserver, actually you do neither send nor request any information that is not already public. So why should it be encrypted? It's the meta data that should be protected! The unencrypted requests and replies that are sent when you use plain HTTP (or HKP), can tell a lot of interesting information. For example, they tell anyone whose keys you ask for, and how frequently. With these data, it's possible to tell who works with you in your Jira or Confluence instance, and how much involved each of the users is – an information that you probably don't want to spread, do you?

As soon as you use a keyserver over HTTPS, this information is hidden. Outside observers will only be able to see that you connect to the PGP server, but all the request and response data will be hidden from them.

So this sounds like a good idea. Are there any caveats?

The Problem With Using the Keyserver Pool Over HTTPS

The good news is, there is a specific url hkps.pool.sks-keyservers.net for accessing the keyserver pool over HTTPS. It's guaranteed to include those keyservers that are able to respond over HTTPS.

Unfortunately, if you try to combine both recommendations – to use the SKS keyserver pool and to use HTTPS – you run into a problem which is caused by the way the pool servers are managed for HTTPS requests. If you just enter this url in the Global Key Management of S/Notify, your connection will most likely fail with something like

Error message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This means, that the responding server uses a certificate which has not been signed by a trusted certificate authority (CA). So why is that?

As (roughly) explained here, the HKPS pool at hkps.pool.sks-keyservers.net uses a self-signed root certificate to sign the SSL certificates of the PGP keyservers in the pool. But because this root CA certificate is self-signed, it is not contained in Java's certificate trust store by default. In order to be able to connect to the pool via HTTPS, the certificate must be added to the trust store first.

How to Fix It

To fix this issue, download and import the self-signed root certificate into your Java trust store. For example, this is how to add the certificate to trust store of the Java runtime that is used by default:

sudo $JAVA_HOME/keytool -import -file sks-keyservers.netCA.pem -keystore <yourJiraOrConfluenceInstallationDirectory>/jre/lib/security/cacerts -alias "sks-keyservers pool"

The password requested to update the Java truststore is changeit unless you changed it.

After having added the certificate to the truststore, restart Jira or Confluence, and everything will work as expected. You will gain a better reliability from using the keyserver pool, and at the same time, successfully prevent unwanted leakage of meta data.

Want To Learn More Every Now And Then?

Want to be kept updated with tipps and tricks regarding S/Notify and email encryption in general? Just let us know, and we'll love to add you to our list. Thank you!