Actually this is pretty obvious; we better ignore such misbehaving servers.

No need for callbacks actually. We can do it in a simpler way. See commit rGe5ef5e3b914d5c8f0b841b078b164500ea157804

SWDB updated - thus the latest zlib will be part of the next Windows build.

I think that the particular issue of Let's Encrypt Certificate was handled correctly already.

I think that this commit rG8fd150b05b74: gpg: Remove all support for v3 keys and always create v4-signatures. matters.

All 4 CVEs are findings related to standard conforming compiler optimizations which OTOH break long standing assumptions on C coding. “Let us show that our compiler produces the fastes code ever and ignore any assumptions coders had made over the last 50 year”.

Great, thank you very much!

Thanks for notifying. Will be fixed in the next release (mid Apri).

Fixed in master and 2.2 branch.

I located the cause; Current implementation cannot parse the data like:

2611:d=5  hl=4 l=1632 cons:      cont [ 0 ]        
2615:d=6  hl=4 l= 500 prim:       OCTET STRING
3119:d=6  hl=4 l=1124 prim:       OCTET STRING

do you mean "dirmngr on Windows choses this one"? As in my mental model, dirmngr only loads all certifices from the windows stores on startup, but not during operations when requests come in (I maybe wrong though, I did not inspect the source code on this).

But in Windows 10 I get nothing in the certs.log file.

In T5639#155478, @werner wrote:

echo BYE | dirmngr -vv --server 2>certs.log

Lists all certificates

@TheParanoidProgrammer this looks like a very good and thorough analysis, thanks again!

Ok, I managed to find 48504E974C0DAC5B5CD476C8202274B24C8C7172 via Powershell. It was in the CA store of my non-privileged user and since I always checked the certificate store as administrator it did not show up there. After removal of this intermediate certificate I am able to use hkps://keyserver.ubuntu.com.

Ok, so order of loading is not a problem since the cache does not store them by insertion order, but instead indexes them by the first byte of their fingerprint.
So, I think the problem here is that the expired intermediate certificate (48504E974C0DAC5B5CD476C8202274B24C8C7172) is somehow loaded in Windows and since its fingerprint's first byte is less than the server-supplied intermediate (A053375BFE84E8B748782C7CEE15827A6AF5A405) Windows chooses this one. I can see that the expired intermediate certificate is indeed loaded on Windows if I increase verbosity of dirmngr logs. However, I am still unsure where this certificate lives. The log says it comes from the "CA" store, but searching for it visually or by fingerprint search in Windows Certificates Snap-In (MMC) does not let me find it.
I will keep looking, but if you want to reproduce in your VMs, I suppose adding the expired intermediate certificate and the expired root certificate to the system store should make this reproducible.

@TheParanoidProgrammer thanks for investigating further. It is highly appreciated!

On a side note, it turns out that Ubuntu Maintainers ship gpg with GnuTLS dynamically linked, so that's why I went down that road first. I compiled gpg from source for Ubuntu with ntbtls for further tests. Interesting insight is that find_cert_bysubject returns different certificates on first try on my Ubuntu Machine compared to my Windows 10 Machine:

Ok, I may see three potential problems in dirmngr->validate.c->validate_cert_chain(), but it may also be my limited familiarity with the gnupg source.

• Here we leave the certificate validation loop at the first trusted root certificate, even if it is expired as we only mark this fact for later evaluation.
• Here we seem to only ever go up the chain, never sideways as is the case in the original patch for this bug.
• And probably most impactful, here we fail the whole validation if any of the previously checked certificates is expired, so that even if we would fix the second point by checking sibling certificates, we would still get an overall failure.

What I wonder is: In a number of tests in our machines (mostly virtual machines), the TLS access to keyserver.ubuntu.com does work. I have yet to see a VM where it does not. So there must be a difference.

Not a solution yet, but some more insights.
Starting from @NoSubstitute 's log output and from @bernhard 's statement that we use ntbTLS I verified that my dirmngr.exe was indeed compiled with NTBTLS 0.2.0. I did so by running strings "C:\Program Files (x86)\GnuPG\bin\dirmngr.exe" | grep TLS which returned "This is NTBTLS 0.2.0 - Not Too Bad TLS" among other strings. I also grepped for some debug strings introduced in newer commits to verify that the NTBTLS version used is not the current HEAD of master, but at least some commit before 64f895dba734802662cbb81b64cd0b4af198ee71. I will just assume it is the actual 0.2.0 release for now.

@NoSubstitute It is okay for me to keep this issue, if most people prefer it this way, was just asking.

@bernard - well, that's the kicker, isn't it.

Ah, just seeing that this issue is resolved. Shall we open a new one to be well structured?
(If we reopen this one, there is a lot of old information in here that does not apply anymore before the fixes that went into dirmngr/gnupg).

Does gpg4win ship a TLS library with gpg or does it use a system default?

Alright, in the hope it helps to pin this down, trying to sum up what I tried during and after my conversation with @bernhard so far:

• Windows 10 keeps both the old and new root CA in the store and manual edits to the root certificate store are undone by the OS sooner or later
• ignoring the intermediate certificate with dirmngr --ignore-cert 48504E974C0DAC5B5CD476C8202274B24C8C7172 fixes the problem as a workaround, but is not a satisfying solution
• I cloned the repository and took a look at the original patch; while it seems that we only check validity of certificates without considering the expiration date, the patch does fix the original bug which I confirmed by compiling gpg from source at the commit containing the patch and another version at the commit prior to the patch. That is, the patch successfully fixes this on my Ubuntu machine. On my Windows 10 machine the bug persists no matter if using a self-compiled version from those commits or the official versions from gpg4win.
• During exploring the source code and finding out how to compile and test from source I found out that I can reproduce the bug on Ubuntu if I compile gpg with the patch applied, but with a GnuTLS version that does not have their patch for this issue. Since this is the case with the default GnuTLS dev sources in Ubuntu 20.04., I had to get GnuTLS library from the project itself in order to successfully compile gpg for Ubuntu. For Windows the problem persists, however. I did not find GnuTLS or any other TLS library in the application directory of the GPG install on Windows nor in the installer itself. So I'm wondering if the remaining issue on Windows is actually with the used TLS library there. Does gpg4win ship a TLS library with gpg or does it use a system default?
• The fixed version of GnuTLS is 3.6.14 for the project itself, there are backports of this patch for Ubuntu Xenial and Bionic, unfortunately not for Focal yet.

Hello.
@bernard has been so kind to try and help me with this exact issue over in the gpg4win forum, and it seems I'm not the only one who still has problems with the "broken" LE certificate chain and hkps://keyserver.ubuntu.com.

Thank you for your suggestion.

Done by rGc8cd66ae7e60: m4: Update our library m4 files from master.

Here is the output of --list-packets of the offending key, anonymised:

1. off=0 ctb=99 tag=6 hlen=3 plen=418 :public key packet: version 4, algo 17, created 985690138, expires 0 pkey[0]: [1024 bits] pkey[1]: [160 bits] pkey[2]: [1024 bits] pkey[3]: [1023 bits] keyid: <KEY_ID>
2. off=421 ctb=b4 tag=13 hlen=2 plen=35 :user ID packet: "XXXXXXXXXXXXX"
3. off=458 ctb=88 tag=2 hlen=2 plen=120 :signature packet: algo 17, keyid <KEY_ID> version 4, created 1629537425, md5len 0, sigclass 0x13 digest algo 2, begin of digest a8 22 hashed subpkt 33 len 21 (issuer fpr v4 <XXXXXXXXXXXXXX><KEY_ID>) hashed subpkt 2 len 4 (sig created 2021-08-21) hashed subpkt 27 len 1 (key flags: 23) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 9 10 11 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID <KEY_ID>) data: [158 bits] data: [159 bits]
4. off=580 ctb=b9 tag=14 hlen=3 plen=525 :public sub key packet: version 4, algo 16, created 985690139, expires 0 pkey[0]: [2048 bits] pkey[1]: [2 bits] pkey[2]: [2046 bits] keyid: YYYYYYYYYYYYYYY
5. off=1108 ctb=88 tag=2 hlen=2 plen=63 :signature packet: algo 17, keyid <KEY_ID> version 3, created 985690139, md5len 5, sigclass 0x18 digest algo 2, begin of digest 94 e5 data: [159 bits] data: [156 bits]

Thanks for the report. To keep things easy the empty comment is now translated to "(none)".

I added --ldapserver to gpgsm because of confusion of what a keyserver is. Right now we see a problem only with this alias but it is a more general problem with aliases. My patch to master was a for public testing - let's discuss this on the phone.

The above change now also makes gpgconf from master ignore the keyserver option in gpgsm.conf.

$ gpgconf --version
gpgconf (GnuPG) 2.3.5-beta17

For what it's worth: I suggest to remove the ldapserver alias of gpgsm's keyserver option in GnuPG 2.2 and 2.3 again. It was added not too long ago (in June 2021) and it was added after the new dirmngr/ldapserver option was added. The alias is causing regressions and trouble with its only benefit (as far as I can see) being that dirmngr has an option of the same name for the same purpose.

For X.509 servers Kleopatra currently looks at gpgsm/keyserver with a fallback to dirmngr/LDAP Server. The gpgconf interface change

* tools/gpgconf-comp.c (known_options_gpgsm): Rename "keyserver" to
"ldapserver" and set level to invisible.

in rG0b4fdbd5f41e: gpgconf: Return --ldapserver and --keyserver from dirmngr. breaks configuration of X.509 servers with existing versions of Kleopatra. I suggest to revert this change to unbreak Kleopatra.

Turns out that the aliasing is a problem; if we allow keyserver as an alias for ldapserver in gpgsm.conf we are not able to get the value unless we add dedicated handling for this. Test in 2.3 but we will have the same problem the other way around in 2.2.

What does kleopatra use to get the list of ldap servers - gpgsm or dirmngr?

The problem comes from the way we handle an alias. That actually depends on the order the options are specified.

Doh! gpgme already performs the unescaping of data retrieved via the Assuan protocol for us in llass_status_handler. Doing it again in Kleo::SCDaemon::getReaders was simply wrong.

Hmm, I looked at the gpg-side a bit. assuan_send_data that's used for returning GETINFO reader_list only does escaping "as required by the Assuan protocol", i.e. percent escaping of certain characters but no plus escaping.

Implemented extended headers for filenames and linknames (on Unix).

While trying to test the X.509 directory server configuration in Kleopatra, I stumbled over difference between 2.2 and 2.3 and a possible regression in 2.2.

@werner Hmm, okay. So I have tested the wrong thing. To me /etc/gnupg/gpgconf.conf looked very much like a global config file I was supposed to test. I have looked at /etc/gnupg, found the example gpgconf.conf and played around with it. It had some effects (see above), so I assumed that it should work. Since it's obvious from my tests, that it doesn't really work as documented anymore, all corresponding code should be removed entirely (or fixed if it should be kept for backward compatibility).

ikloecker: gpgconf.conf ist not anymore used since we have the global config files.

With /etc/gnupg/gpgconf.conf

[empty lines and comment lines]
*	gpgsm	verbose				[no-change]
	gpgsm	quiet				[no-change]
	gpgsm	debug-level			[no-change]
	gpgsm	log-file			[no-change]
	gpgsm	include-certs			[no-change]
	gpgsm	compliance			[no-change]
	gpgsm	default-key			[no-change]
	gpgsm	encrypt-to			[no-change]
	gpgsm	keyserver			[no-change]
	gpgsm	disable-dirmngr			[no-change]
	gpgsm	auto-issuer-key-retrieve	[no-change]
	gpgsm	p12-charset			[no-change]
	gpgsm	disable-crl-checks		[no-change]
	gpgsm	enable-crl-checks		[no-change]
	gpgsm	disable-trusted-cert-crl-check	[no-change]
	gpgsm	enable-ocsp			[no-change]
	gpgsm	disable-policy-checks		[no-change]
	gpgsm	cipher-algo			[no-change]

all options are correctly flagged as "no change" in the output of gpgconf

More weirdness. With gpgconf (GnuPG) 2.2.34-beta23 I get:

After commenting out the options that gpgconf 2.3 complains about I get:

$ gpgconf --version
gpgconf (GnuPG) 2.3.5-beta17
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I tried to see what gpgconf from master says, but I only get

$gpgconf --list-options gpg
gpgconf: unknown option 'try-secret-key' at '/etc/gnupg/gpgconf.conf', line 95
gpgconf: unknown option 'reader-port' at '/etc/gnupg/gpgconf.conf', line 96

This also doesn't look right:

The following looks very much like a bug.

Example:
/etc/gnupg/gpg.conf:

default-key B81CE112B26A8EA8BE7B95D2E375339BF4C51840

With rG8c878ae4c9dfa9fe26aa15f4f9db3e86833575e9 some rules for allow-mark-trusted were removed from doc/examples/gpgconf.conf, but the comments below which are supposed to explain the example rules still talk about allow-mark-trusted.

Backport done but diligent testing is required.

@ikloecker yes sorry ok

@bernard Right sorry. I have sent request to mailing lists

@alexnadtoka, please stop adding the same information to two different issues. Let's use T5744: Issue with connecting to GPG server for any further comments.

@alexnadtoka wrote:

both versions had issues(( and send two requests to RU and EN comunity . No answer for two days already

@bernhard yeah thank you. both versions had issues(( and send two requests to RU and EN comunity . No answer for two days already
The log clearlys says certificate is expired(( but it is not at least for keyserver... May be it is reffering to gpg key... I dont know... but it is not expired either. Probably I am missing something. Will try to contact community again.

@alexnadtoka When using Gpg4win-4.0.0 or 3.3.16 with an updated GnuPG the validation of dirmngr works fine with the Let's encrypt certificates again. If you have one of these versions, and you still have problems, you need to be more specific about which connection you are referring to.
Maybe it is best to ask on one of community channels (e.g. the gnupg-users mailinglist, see https://gnupg.org/documentation/mailing-lists.html )

@alexnadtoka, did you do what Werner wrote in T5639#150626?

Guys I am facing similar issue but my Lets ecnrypt certificates are all ok. What is the problem with my gpg4win client? When connecting to openpgp server it says certificate is expired. Anybody can help me?

A clumsy workaround for the Kleo bug is to put "keyserver ldap:///" into the global gpg.conf after an ignore section containing keyserver. This will let gpgconf emit "ldap:///" unless a local gpg.conf exists.