There's a wildcard CNAME, it's not _really_ configured. It's not a good assumption that a CNAME == configured and it doesn't have a reasonable fallback, IMHO.

If you configure the subdomain in the DNS this will be used. Thus get a cert for it. The old method should not be used and thus if the openpgpkey subdomain exists gpg concludes that the admin is aware of the new scheme.

Hm, I don't want to remove the CNAME just so that GPG WKD would work, is there a way to fix this? Is there a good reason why after "Advanced"/subdomain lookup it doesn't try "direct"?

Oh, it's using the openpgpkey subdomain because of the CNAME but that's not actually being served by the server.

Nope, of course SNI is used. You problem is a different one. For example no root certificate, a server configured to allow only TLS 1.3, or a not supported algorithm. Decent versions of GnuPG print some hints if run with -v. BTW, an easier way to test is to use "gpg --locate-external-key" which basically does the same you did.

Should work now with GnuPG master (from today). Probably also works with GnuPG 2.2.18.

In T5150#140039, @gniibe wrote:

With little (mostly no) knowledge of NKS card, I think I fixed this issue.

With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:

2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2)
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed
2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0
2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0
2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0

Thanks a lot for your time to locate the problem. I took the approach of #2.

I have reproduced the bug

A backtrace with gdb from migw-w64 results in

I did a fresh install of Gpg4win 3.1.14 and imported my standard pubkey, by using

gpg --locate-key bernhard@intevation.de

on the command line.

This works now. Thanks.

I'm not sure why I thought that it would work now. With current master I get

$ gpg-connect-agent "SCD READKEY --info-only -- 39400430E38BB96F105B740A7119FE113578B59D" /bye
ERR 100663414 Invalid ID <SCD>

Sorry, I can' reproduce thus. What kind of key is causing the crash?

I am affected by the same bug and the patch seems to work for me. Login via gpg-agent with ssh support is possible again, which wasn't before, since some openssh and/or gnupg update. Not sure.

Should work now with GnuPG master (because PIV is not supported by 2.2).

Should work now with GnuPG 2.2.18+, but so far only tested with master.

Fixed.

I checked the development log for the addition of:

libusb_clear_halt (handle->idev, handle->ep_intr);

In T5167#139966, @gbschenkel wrote:

I have another yubikey neo but its clean. Can it help it?

I have another yubikey neo but its clean. Can it help it?

In T5167#139964, @gbschenkel wrote:

Changing modes will I lose/change my OTP and FIDO codes?

Changing modes will I lose/change my OTP and FIDO codes?

I would add "Provide a verbose message of why the key cannot be imported".

Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334

Pushed the change by Ingo.

I finally recognize this change: rG638526d37fee: agent: Allow signing with card key even without a stub key..
I should have seen this yesterday.

Thanks a lot.
Let me explain the situation.

Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break.

Sorry, no. Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break. Even when we added lines starting with the usual comment sign (#) to indicate the offset of the packet, we received quite some bug reports. Thus such chnages will only be done when they are really needed. For all other the rule is still: Use the source, Luke.