Thank you! But let me mention, that my older smart cards (Version 2,2) holding also RSA-4096 keys. They could be generated on card without any problem. I had the problem only with OpenPGP cards version 3,4. This I would like to strenghten.

My setting is RSA-4096 key. Also it showed "pipe was broken", but it disappeared too quickly, so I do not have a screenshot from that.

I started "gpgconf --launch gpg-agent" and afterwards PuTTY. Then I am asked to "login as:". After entering the username, the error "PuTTY Fatal Error: No supported authentication methods available (server sent: publickey)" occurred.

I used already the mentioned blog ass base of my work. But the Yubikey is not recognized in ssh and I do not know how to mitigate.

Sorry, my fault. I found this command line in the internet (I am relatively new) so I mixed it up. Ok, skip ssh-add, it was my mistake! But the problem is that my Yubikey is not recognized by PuTTY in an ordinary ssh session. In the cmd window and in Cleopatra it works, but not with PuTTY.

No, you are wrong, I speak not about OpenSSH!!! I speak from PuTTY. As explained in my first message, if I copy my ssh key on an USB stick and if I use PuTTY in combination with this stick, it is fine, I can connect to my server. If want to use my Yubikey 5NFC in combination with PuTTY, ssh authentication fail!

The new Yubikey 5Ci does NOT work with NFC, this is wrong. This Yubikey is delivered with two connectors: A lightning and an USB-C, see: https://www.mtrix.de/shop/yubikey-5ci/. The key can be connected to a laptop and an iPhone by plug-in. So the new Yubikey 5Ci does not require NFC at all. You refer to the Yubikey 5 NFC. This technology is not supported by developers because they do not have experiences there. With the plug and play functionality of a lightning connector it is easier and few application already exist (e.g. Yubico authenticator and several password manager in the professional edition). Hope this information will be useful for you.

At least one configuration error I could identify by myself: Kleopartra -> GnuPG-System -> Smartcard -> Connecting Reader with port N. If it is written: Yubico YubiKey OTP+FIDO+CCID 0 then Yubikey is recognized. I forgot to write "Yubico Yubikey" at the beginning and the "0" at the end. Now smart cards and Yubikeys are working for gpg. What is still a problem is SSH. A SSH key is on smart card or the Yubikey.

Werner, no silly questions exist, only silly answers are existing. However, Yubikey is enabled for usb. I using Yubikey Manager a GUI, for the USB interface it is enabled: OTP, FIDO, FIDO U2F, OpenPGP, PIV and OATH. Thanks also for the suggested command line test. Indeed an error code shows up:

Please, note the following uncommon behavior:

Today a new signed message from BSI Buerger CERT was received. The PGP signature could be verified by first opening of the document. As I opened the file some hours later again, it failed, as I opened it a third time (shortly after the second time), the signature was verified. Outlook was not closed between the second and third opening. Signature verification appears unstable.

The signature of the latest communication from German Buerger CERT Warnings could be read and the signature could be verified. I tried also with Hasso-Plattner-Institute (Identiy leak checker), the same result. I do not understand, why all signature verification failed last week, and they can be verified this week. However, at the moment it seems to work fine.

I have the same problem since today with Outlook 2016. In the past months / weeks GpgOL version 2.4.2 worked fine. I received some mails today signed by the German Buerger CERT warnings. The signature as "asc" file was attached, but could not be verified. Today I received also a PGP signed e-mail from Hasso-Plattner-Institute (Identity leak checker), also this signature could not be checked. Both worked fine in the past and the public keys stored in Kleopatra are valid.

The card was replaced by the vendor. It seems to be a problem with the specific card. All other cards so far worked well. The issue can be closed.

I applied the following with gpg-connect-agent --hex:

I do not wonder, that you face difficulties to reproduce it. It happened only with one card from my six cards; so five cards working fine. Therefore, I thought that this particular card was may dead at arrival and I contacted the vendor. They refused to replace it with the comment, it would be a well known issue. Do you know a test where I can demonstrate that the card is dead at arrival?

I use the internal driver.

All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.

I should may add, that on the card which failed, only the signature key was generated and written to the card. The authentication and encryption keys could not be generated..

Hi Maximilian,

Thanks, this is excellent news! I´ll check it, if the new Mailvelope version is available and I´ll let you know about the outcome. If the new version is released, let me know!

The problem could be narrowed as follows: According to Mailvelope Add-on, GnuPG must be installed for smart card support. Screenshots show that GnuPG is not recognized by Mailvelope. Of course actual versions off all programs were installed. Therefore, e-mails sent out ecrypted with public key work fine, because the public key is stored in Mailvelope. Is the encrypted message arrives and should be decrypted. Mailvelope does not find GnuPG and therefore, no private key. I´ll send some screenshots to you.

On think should be mentioned. Both accounts are IMAP, but the Posteo account has one particular feature. All inbound traffic from their server to my client (receiving e-mails) is encrypted with my own public S/MIME certificate (they call it "Eingangsverschlüsselung") so all non-encrypted e-mail will be treated between Posteo server and my client as S/MIME end-to -end encrypted e-mails. This is not the case with the t-online account (there it is just TLS encrypted). However, I believe a PGP signature verification should happen after S/MIME decryption on the client.

This account is IMAP, nothing special, I´ll send a screenshot from the add-ins by e-mail.

Well, I deinstalled gpg 3.1.7 and reinstalled it. For some reason my two gnupg smart cards work fine, but my two Yubikeys cannot be detected anymore (no such device). But in the last weeks, they were deteced, only the switching between Yubikey and Smart Card made some trouble. That they cannot be recognized is new and makes real trouble. If you think it would maybe helpful, I can submit a scdaemon.log file by e-mail.

The debug file will be sent by e-mail to you immediately. THANKS

So long I change between smart cards, I can do it multiple times. If a Yubikey is recognized and a smart card follows next it will not work. Most recently I face also problems to detect the Yubikey (Message: no such device), but Smart Cards still working fine.

Did you get the screenshots from Thunderbird (works fine in both accounts) and Outlook (failure in one account)? If not, please provide e-mail address.

Screenshots were sent by e-mail to you. Thunderbird and Outlook screenshots are different.

I am quite sure! Because, (1) I opened both mails on another computer were Thunderbird is installed. Both signatures can be verified on both accounts with Thunderbird. Both mails were sent out with PGP signature by HPI Identity Leak Checker Team, so the signature generally works fine. (2) If I save the key which is as asc file in the attachment (in the account which does not work) on computer and perform then a check of the signature, I receive a input / output error in Kleopatra. I will make some screenshots, and I´ll send it by mail to you.

By installation from version 2.3 an error occurred, I´ll send you a screenshot by e-mail. However, I have some comments to the current version which may also help: I have three keys, two on smart cards and one on a Yubikey. So long as only smart cards are used, it is no problem to change between the cards and they work fine. Problems occur, if a Yubikey comes in. (i) Not always a Yubikey is recognized by pressing F5. (ii) It the Yubikey is recognized and next a key from a smart card is needed, a computer restart is required.
I tried also command: gpgconf --kill gpg-agent
It was possible to change from smart card to Yubikey with the command. However, if the Yubikey 5 NFC was recognized, the only way to change back to the smart card was a restart of the computer.

I´ll give it a try for sure! Probaly next weekend, so my feedback will be sent next week. Please, keep the file open. THANKS

After re-start, the smart card will be recognized in proper way and it works. I assume it has something to do with using Yubikey and smart cards with different keys alternatively. The Yubikey was not found originally, so I modified the following:

Kleopatra recognizes the smart card, shows the correct version number and keys in the "smart card - management" window. In the Keylist I can´t find the key. Currently GnuPG 2.2.15 is installed. Do you know then version 2.3. will be released?

Well, I can narrow the root case. A Yubikey 5 was successfull installed and can be used. Then I started to test the OpenPGP card. I recognized, that by pressing F5 in Kleopatara a change between YubiKey and Smart Card happens. However, if I test it via command line, Yubikey does not change, although it is dismounted and the smart card is inserted. Probably therefore, the private key cannot be found. It should be mentioned that I have a computer with integrated smart card reader. First I configured the card, then the Yubikey. I started to test the Yubikey first. Therefore, I believe it is a mess in detection of smart card / Yubikey if used parallel.

I agree! THANKS

Indeed in view of this data, it seems to be that the problem occurs by Microsoft. It fits also with the fact, that all other signatures are working fine from my experience.

A pristine file I do not have, because every file passes GpgOL before displayed. I suggest, you subscribe to the service and if you de-install GpgOL, you should obtain a pristine file.

No, I can´t confirm it, I get no reason displayed. The key which I use is shown in my screenshot (I´ll send by e-mail)

I must make a correction of my earlier statement from today. The three Microsoft messages were not displayed in the same order on the screen on both machines. I must say, that on Outlook 2016 AND Thunderbird PGP verification still fails by "Microsoft Security Update Releases". It is the same situation as last year, nothing has been changed. I sent two files in EML format and some screenshots to A.Heinecke today.

Yesterday Microsoft issued three PGP signed mails. It is the first communication after MSRC confirmed failure of verification and promised to have internal procedures changed. I received those mails on two different machines, one equipped with Outlook 2016, the other with Thunderbird. Last year all messages failed on Outlook and Thunderbird, if the were issued from "Microsoft Security Update Releases".

Please, provide e-mail address, then I´ll send it asap

Very strange, but I tried it by myself, after your mail. The same for me. However, I can offer you to send two mails to you as EML files, one works, the other not. I using GnuPG also for verification from BSI newsletter, it works fine there. The problem is only with newsletters from "Microsoft security update releases", other Microsoft security notifications can be verified as well.

Yes, GpgOL in version 2.3.2 fails to verify the original message, it is labeled as "not-secure". But it happens only to "Microsoft security update releases", not to other Microsoft Security Notifications which I receive on regular base. I contacted Microsoft Security Responce Center (MSRC) and they confirmed the failure of signature verification in this case. They were not aware about it, but checked it by them self after my mail. They had no explanation for that. Labeling the message as "not-secure" would may indicate that it would be altered in transport, but MSRC did not say that. Therefore, I still assume, that we have a bug in GnuPG.

I contacted Microsoft Security Response Center (MSRC) in regard to this matter. They confirmed the failed PGP key verification, but have not yet any explanation for that.

Sure, I zipped the eml which failed and I´ll send it by e-mail to you

I checked my mails in detail, and I can confirm that the error occurs only with "Microsoft security update releases". Indeed "Microsoft security advisory notification" and "Microsoft security update summary for..." will be verified correctly.

My problem isn´t linked to forwarding encrypted e-mails and / or attachments. It occurs by ordinary PGP mails WITH attachments which are not ASCII format. Encrypted e-mails without attachmoments or in ASCII format will be delivered.

Default settings in Outlook are as following: (i) S/MIME encryption disabled, (ii) S/MIME signature enabled.

Indeed, I use a S/MIME certificate in Outlook for signing by default all e-mails. However, if I intend to send a PGP mail, I manually disable this feature and I manually opt for PGP signature & encryption. I am sure, that this standard procedure applied in this case. Therefore, I am surprised, that the message appears.

Thanks for the quick reply!

I decided today to install the beta version and give it a try, because the final version is not yet released. I still facing major problems, see attachment. The mail will not be delivered, but Outlook does not crash as before.