2022-02-10 17:07:35 [12256] dauerhaft geladene Zertifikate: 74 2022-02-10 17:07:35 [12256] zwischengespeicherte Zertifikate: 0 2022-02-10 17:07:35 [12256] vertrauenswürdige Zertifikate: 74 (74,0,0,0) 2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> # Home: C:\Users\User\AppData\Roaming\gnupg 2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> # Config: .\dirmngr.conf 2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> OK Dirmngr 2.3.4 at your service
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Feb 10 2022
Feb 10 2022
Feb 8 2022
Feb 8 2022
In T5813#154705, @bernhard wrote:@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.
Feb 7 2022
Feb 7 2022
In T5813#154552, @Valodim wrote:Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?
Either way, I hadn't considered this for the WKD relay. I'll look into enabling AES-CBC there, at least for backwards compatibility.
Feb 2 2022
Feb 2 2022
After further testing: The error does not occur if WKD is implemented directly under the respective domain.
The behavior of GnuPG differs between Windows and other platforms. However, it is not clear to me which version is behaving incorrectly. But it seems clear that there is no compatibility with the instructions at https://keys.openpgp.org/about/usage#wkd-as-a-service under Windows. (However this may concern another project.)
The server in the testcase is wkd.keys.openpgp.org which is referred with CNAME via the DNS. Referring to https://www.ssllabs.com/ssltest/analyze.html?d=wkd.keys.openpgp.org it shoud support TLS 1.2