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 mail@example.com 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.

BlastingAgent
  • 93

1 Answers1

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.
Preston Maness
  • 1,977