sks.spodhuis.org, a mostly private keyserver providing HKP access to keys on ports 11371, 80 and 443. Note that while port 11371 does not require a Host: HTTP header, ports 80 and 443 do, and port 443 requires TLS SNI to serve the correct certificate.
This service may be withdrawn at any time and without notice to end-users. (Peers will be notified). End-users should use a pool definition, such as keys.gnupg.net which will alias into an operational pool.
2017-10-03: This service is temporarily withdrawn.
Note: this service is provided free, to the public, in the hopes that it might prove useful. No warranty is provided, nor any offer of continuing service or access. By using this service, you MUST understand that presence of data in the keyserver (pools) in no way connotes trust. Anyone can generate a key, with any name or email address, and upload it. All security and trust comes from evaluating security at the “object level”, via PGP Web-Of-Trust signatures. This keyserver makes it possible to retrieve keys, looking them up via various indices, but the collection of keys in this public pool is KNOWN to contain malicious and fraudulent keys. It is the common expectation of server operators that users understand this and use software which, like all known common OpenPGP implementations, evaluates trust accordingly. This expectation is so common that it is not normally explicitly stated.
For administrative questions, contact any of the non-revoked email addresses in my PGP key. (Use verbose index to see which are revoked.) Or use keyserver as the left-hand-side, in the domain spodhuis.org.
Note that this host peers as
sks-peer.spodhuis.org and SKS-protocol peering requests are often accepted; I'm willing to set up email-based exchange for non-SKS speakers.
For more information on PGP, try starting at: Mr Dibowitz's PGP pages.
For more information on SKS keyservers, see www.sks-keyservers.net which maintains current status listings and a map of the keyserver connectivity. Meanwhile SKS is nongnu GPL software. The code site is hosted on Atlassian BitBucket and the wiki there does not yet contain much, but does include a guide to setting up peering, written by me.
Some more information about PGP keyservers in general, focusing on HKP-speakers (such as this one) is available on this author's personal pages.
Keys sign other keys, building up a “web of trust” based on chains of signatures. If you group the keys together based on existence of paths between them, to make multiple islands of keys, then the largest such island is the Strong Set. Henk Penning has a page with more formal definitions and various statistics. If your key is in the Strong Set, then you can use tools which find the paths between two keys to find the keys you might need to reach another key in the Strong Set, if you decide to trust those intermediates.
This keyserver peers as
The code for the mesh is available on GitHub.
The main HKP pool which you should configure your keyserver software to use is
ha.pool.sks-keyservers.net, or perhaps
pool.sks-keyservers.net. Folks will understand and expect that choice. (Also
Separately, as an experimental service which I do not expect folks to use, I run my own pool definition. I give it an obnoxiously long name specifically to discourage its use. This is
keys.sks.pool.globnix.net (plus also
This keyserver pool was, to my knowledge, the first to use statistics to find reasonable means for inclusion independent of the count of keys on any given server. Although Kristian beat me to a geocoded pool, even though I was first to have geocoding of IPs collected in the spider server. A little competition is healthy.
At time of writing, my operational pool filters the included servers (after key count elimination based on all reasonable servers) to those running at least version 1.1.2 of SKS, by pulling the URL: http://sks.spodhuis.org/sks-peers/ip-valid?minimum_version=1.1.2.
In addition, as a feature copied from sks-keyservers.net, I have
keys.ha.sks.pool.globnix.net (plus also
keys.ipv6.ha.sks.pool.globnix.net). My variant defines ‘ ha’ as “either we got a Via: header, or we got a Server: header which was neither sks_www nor GnuKS”.
Similarly, with the same three variations in hostname, depending upon content of the mesh there may be entries for:
None of these currently have the proxy-in-front constraint; some do have the minimum version constraint. If no servers meet the selection criteria, then the entries will not exist in DNS (NXDOMAIN, rather than NOERROR).
All keyserver clients must use TLS 1.0 or greater, and must send ServerNameIndication in the TLS handshake. While there is no standard stating this, operation of the public keyservers in practice requires it.
Each keyserver implementing TLS is currently doing so with a “reverse proxy” in front of SKS (or equivalent), and the proxy handles TLS termination. In practice, a keyserver can be known by many names and each keyserver operator chooses for themselves what certificate policy they choose for names which identify just their keyserver. Separately, a keyserver DNS pool operator can choose entry criteria for their pool and work with the individual operators to make that work.
At present, there is one public pool collecting HTTPS/TLS servers, hkps.pool.sks-keyservers.net. Membership in that pool uses certificates signed by a root CA certificate (and detached PGP signature) issued by Kristian Fiskerstrand. See the GnuPG configuration instructions on www.sks-keyservers.net/overview-of-pools.php.
Operators generate a key for the relevant vhosts, send a CSR (PGP signed) to Kristian, who issues a TLS X509v3 cert for use for the relevant vhosts. Thus the need for ServerNameIndication. (The sks-keyservers.net root CA cert is also available on this site (signature) and on my security site (signature), where it is available over https with an X.509 TLS certificate issued by a root CA in most common browsers.)
hkps://sks.spodhuis.org/ uses a certificate issued by Let's Encrypt. Historically it was issued by the server operator's private CA. No guarantees about what will be used in the future, but we're currently happy with Let's Encrypt.
Some other test names use a certificate issued by the server operator's private CA, which there's no reason for the general public to trust. This operator is currently willing, at his discretion, to work with anyone else setting up a pool, providing vhosts.
The ServerNameIndication (SNI) sent should be the trusted name supplied by the user (or config) and not derived from DNS (via SRV records), perhaps unless DNSSEC is used. It's simplest (and likely correct) to just mandate “never chase names from SRV, even with DNSSEC present”. This name is used for selecting the certificate, and should then be used for validating the cert during the handshake. (In GnuPG terms, leave “ --keyserver-options check-cert” turned on).
The choice of name for SNI is not correctly handled in current GnuPG releases [issue 1447] (awaiting word from GnuPG folks to confirm that they agree this is a bug).
The “hkp:” (& “hkps:”) URL scheme is effectively HTTP, with a different default port and a template for constructing a query given a search term. There is no published standard; there was a draft, and today the de-facto rules are “whatever the SKS developers and GnuPG developers agree to between them”.
Thus the default port for HKP is 11371; the default port for HKPS is 443.
The SRV records used are for _pgpkey-http._tcp & _pgpkey-https._tcp respectively.
Bugs in some releases of GnuPG might cause the port number from the SRV records to be ignored. [issue 1446]