0

I'm trying to set up a Web Key Directory but both, the Direct and Advanced configuration according to https://wiki.gnupg.org/WKDHosting fail.

Testing the setup with gpg -v --auto-key-locate clear,wkd,nodefault --locate-key [email protected] results in the error that the certificate expired everytime. Both certificates are LetsEncrypt certificates by the ISRG Root X1 CA.

I read here that this might be a problem due to the DST Root CA X3 expiring. The GnuPG versions I tried are 2.2.28 and 2.3.4. I also tried the discovery with Thunderbird, which gives the error "Can't read public key file".

Is this still a problem due to the expired LetsEncrypt CA or is there something else that I might have misconfigured?

The Access-Control-Allow-Origin header and policy file are in place, the data is sent as an octet-stream.

Unfortunately, my web hosting provider only uses LetsEncrypt and for my locally hosted server I don't have an alternative for LetsEncrypt as well - if that is the problem, is there any workaround for the issue? Upgrading my local configuration wouldn't be very helpful, since I want my keys to be discoverable by other parties with presumably older software as well.

1 Answer 1

2

I read here that this might be a problem due to the DST Root CA X3 expiring. The GnuPG versions I tried are 2.2.28 and 2.3.4. I also tried the discovery with Thunderbird, which gives the error "Can't read public key file".

The link you gave indicates that the problem probably isn't with specific client applications (like gpg or Thunderbird) per se. The issue is (probably) that the applications are linking against old versions of TLS libraries:

If your OS only has the IdenTrust "DST Root" CA but not the Let's Encrypt "ISRG Root" CA installed &ndahs; or if it has both but your GnuPG version is linked against a TLS library that doesn't support alternate verification chains – it will then reject the server's TLS certificate as "expired" because its root CA is expired. Old versions of GnuTLS and OpenSSL don't realize that this isn't the only option.

https://superuser.com/a/1682118/220550

So long as the client that's talking to the LetsEncrypt-signed endpoint is old enough that it can't handle this scenario, then no, there is no work-around. LetsEncrypt is going to keep using certifications that have this scenario, because:

(The reason Let's Encrypt still offers this as the primary chain is because it happens to provide better compatibility with really old Android versions.)

https://superuser.com/a/1682118/220550

This means either

  1. Clients that need to talk to your Web Key Directory that's protected with LetsEncrypt certifications need to update themselves in order to handle this scenario, or,
  2. Change the certificate that the Web Key Directory is using to one that the old clients can process without needing to update.
3
  • Oh, I was under the impression GnuPG shipped with GnuTLS under Windows, that's why I specified the versions I tried - if all of the clients I mentioned link against the same TLS library, using a different client won't change anything of course. So, I spun up a debian bullseye, where the discovery finally succeeded, so it seems indeed to still be the expired CA that's being problematic. Since I unfortunately have no control over the certificate used by my web provider whatsoever, the only possibility to make it work for older clients would thereby be to change the provider, right? Commented Apr 15, 2022 at 19:34
  • 1
    Correct. Either that, or update the older clients. A distant third option would be to try and set up some sort of proxy between the older clients and the provider that can handle both supporting the older clients and ferrying connections between itself and the provider. Commented Apr 15, 2022 at 20:03
  • Alright, thanks for the help! My clients are all up-to-date. Anyhow, I know how to make discovery work, but the whole thought behind WKD for me is that any client that knows about it can automatically retrieve keys without me needing to promote GPG or, depending on the client, even without any user intervention - since my Windows machines are up-to-date and can't retrieve the key, basically all currently deployed Windows machines won't be able to and, knowing the sluggish deployment of updates in companies in general, won't be for the next five years at least... Commented Apr 18, 2022 at 16:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .