[null, {"document_url": "https://roll.urown.net/server/pgp-keyserver.html", "unformatted_src": "../_images/pgp-keyserver.png", "src": "https://roll.urown.net/_images/pgp-keyserver.png", "formatted_filename": "pgp keyserver", "alt_text": "OPDS Logo"}, null]
PGP Key Server¶ A Public Key Shelf¶

Keyservers play an important role in public key cryptography, as the name implies, the public keys need to be distributed publicly.

Keyservers act as central repositories to distribute these public keys.

In OpenPGP clients connect to OpenPGP keyservers to import public keys it needs, if they are not already stored in its local public key-ring. Keys also need to be updated, after they have changed or revoked.

OpenPGP clients and keyservers use the HKP (OpenPGP HTTP Keyserver Protocol) protocol or HKPS for the the TLS secured version.

How Can I Trust a Keyserver?¶

Since the keyserver plays such an important role we have to put a great deal of trust in the keyserver and its operators:

So the short answer to the question above is: You can’t!

The Keyserver Pool¶

But to mitigate the risk of anyone surveying or controlling this important part of the “Web of Trust” keyservers have been organized in large pools of individual keyservers.

A pool is maintained in DNS. When a OpenPGP client needs to talk to a keyserver he asks for the IP address of the host hkps.pool.sks-keyservers.net. A DNS lookup for this host returns many IPv4 and IPv6 addresses of which the client will randomly select one to connect to.

The domain sks-keyservers.net is secured with DNSSEC and therefore can not by spoofed easily.

The keyservers in the pool are run by organizations and individuals voluntarily all over the Internet. Everybody can setup and run a keyserver and thus become part of the pool.

The Synchronizing OpenPGP Key Server (SKS)¶

To run you own keyserver, be it for your own personal use or network, or to be part of the pool, run the Synchronizing OpenPGP Key Server (SKS) software on your server.

SKS is an OpenPGP key server that correctly handles all OpenPGP features defined in RFC 2440, including photoID packages and multiple subkeys.

This keyserver implementation uses an efficient and reliable reconciliation algorithm to keep the database in sync with other SKS servers. Additionally it can both send and receive PKS style sync emails.


Storage Space¶


SKS Mailing List¶

Join the SKS mailing list where you can ask for peers and will get notified about software issues and updates of SKS.

Database Dump¶

Rather than starting with an empty database and attempting to populate it by syncing with other keyservers (a bad idea because it loads up your peers with lots of traffic and will probably fail anyway with deadlocks in the conflict resolution system) we’ll grab a static dump from an existing SKS server. Currently known sources are:

As of November 2018 the archive size is approximately 11G, holding over 5 million keys in 90 files.

The download can take several hours. Thats why we start this first in screen session and let it run.


Don’t download from the current directory on the server! If the server creates new dump files while you are downloading you will have to start over again. Use the directory with the latest date.

The dump is divided into a bunch of individual numbered files so you’ll need to fetch all of them.

Proceed to import the database dump, when the download completes.

SKS Daemon User¶

For security reasons its best to run the daemon with its own unprivileged user profile. Create this user on the server system with the following command:

IP Address¶

Add IPv4 and IPV6 network adresses for the keyserver:

Also add them to the file /etc/network/interfaces to make them persistent across system restarts:

DNS Records¶

Check the “Add also reverse record” when adding the IPv6 entry.

Firewall Rules¶

IPv4 NAT port forwarding:

Allowed IPv6 connections:

Tor Hidden Service¶

Add a Tor Hidden Service by editing /etc/tor/torrc:

Reload the Tor client:

Read the newly generated *.onion hostname:

Software Prerequisites¶

To build, install and run SKS from source we need the Gnu C-compiler, the Ocaml programming language and the Berkeley database libraries.

They can be installed from the Ubuntu software repository:

SKS Source Download¶

As of September 2016 Ubuntu 16.04 has SKS version 1.1.5 in its repository. Since the servers eligible for inclusion into the SKS server pool need to run version 1.1.6 we install a newer version.

We download the source code from the SKS project website.

The source code is signed by the SKS Keyserver Signing Key. The KeyID and fingerprint are published on their website, which is a secure site wit EV certification to Altassian Inc.

Get that in our keyring, so we can verify downloaded source code is legit:

Be sure to check that, key-id, name and fingerprint all match with the published information:

If everything checks out, sign the SKS key as trusted:

Now go ahead to download:

Verify the downloaded file:


Edit Makefile.local by changing the following lines as highlighted below:

Build and Install¶

SKS Configuration¶



System Configuration¶

The following is adapted from the Ubuntu/Debian SKS software package.


Create a system envoronment for SKS, change ownership of the data directory and various other stuff:

System Service¶



Daily Cron Job¶


Log Rotation¶


Nginx Web-Server Configuration¶

For better performance and as requirement of the SKS keyserver pool, SKS traffic is handled by Nginx and sent to SKS as a reverse proxy back-end.



SKS Web Application¶


Keyserver Website¶

Keyservers can be accessed by normal web-browsers, apart from OpenPGP clients. Typically you can search for, view, download and upload keys on a rudimentary web-interface. They usually look like the web was invented only last week.

Luckily Matt Rude has created a more modern OpenPGP Keyserver Website available from Github:

Restart Nginx¶


The Problem¶

With our Nginx configuration web-browser can access the HTML interface over plain unencrypted HTTP on the standard HTTP TCP port 80 and the non-standard HTTP (but standard HKP) TCP port 11371. For the security aware encrypted HTTPS connections are provided on port 443. the standard TCP port for both, HKP and HTTPS.

Now if your domain and sub-domains have strict HSTS enabled, this creates a problem.

If a modern browser is directed to a website on a non-standard TCP port in a HSTS enabled domain, the browser will attempt to initiate a TLS connection on that port, even if the URL starts with http:// and not https://. If that fails, an error page is displayed to the user and thats it.

So users visiting our keyservers web-interface on port 11371 will be greeted with a security error message.

This behavior may seem strange but its currently the only way of ensuring security. The browser MUST enforce HSTS but also has no secure way to learn about or assume on what other presumably non-standard TCP port number, he could attempt a secure connection.

The problem and and subsequent decision on how this needs to be handled are described in this blog post by Andy Steingruebl.

The Workaroud¶

There is software who can sniff out the protocol connecting on a given port. OpenVPN for example supports this, so you can hide your secret VPN gateway behind a unsuspicious website and may also help clients to connect trough overzealous firewalls.

sslh is one such an Applicative Protocol Multiplexer who allows to run multiple protocols on the same port.

sslh Installation¶

sslh is available in the Ubuntu, Debian, SUSE and Fedora software package repositories:

sslh configuration¶

Configuration is stored in the file /etc/sslh.cfg. The installation does not create that, but an example configuration file is provided in /usr/share/doc/sslh/examples/example.cfg.


Launch it by hand to see of it is working alright:

Then open https://keyserver.example.net:11371/ with your browser.

Output should look about as follows:

If you got a connection from the SKS pool testing scripts during your test-run, you may visit your server status page on the SKS pool website, to see if it still works.

Set up as Service¶

If test are successful, set it up as service.

Open /etc/default/sslh.

Start the Service¶

Database Import¶

Lets hope the download of the database dump we started earlier has completed in the meantime.

If so check that all the pieces have been downloaded correctly by comparing their checksums against the list published by the dump provider:

The dump now needs to be imported into the SKS database. There are two ways to do this: either a full build (which reads in the dump you just downloaded and leaves you with a complete, self-contained database) or a fastbuild (which just references the dump and requires it to be left in place after the fastbuild is complete):

On the next screen, choose 2.

This took around 4 hours on my machine (Intel Core2 Duo CPU @ 2.10GHz with 3GB RAM) doing a normal build (option 2).



If you have even more disk space available on your server, you can run additional instances.

Copy the database directory:

It might take a few minutes to copy 23 GB of data.

Copy the configuration directory:

Edit the new configuration file /etc/sks2/sksconf:

Edit the new configuration file /etc/sks3/sksconf:

Edit the new membership file /etc/sks3/membership: