FAQ on User Issues
This section provides answers to frequently asked questions about common issues users may encounter when using the software.
You'll find additional FAQ sections here:
Encryption using public keys and certificates
Why does Kleopatra say “No secret key” when decrypting?
This error occurs when Kleopatra can't find a matching secret key, in other words, a key that fits the encrypted file.
Common causes:
- The sender forgot to add your certificate as a recipient when encrypting the file.
- The wrong certificate was used by mistake.
-You created a new OpenPGP key pair but didn't revoke the old one. Now two certificates exist with the same user ID, but only the new one includes a secret key.
What to do?
Ask the sender to encrypt the file again and this time, to select your current certificate under Encrypt for others in the file encryption dialog.
If you're unsure, just send your current certificate to the sender again, ideally along with any older versions (expired or revoked) that use the same user ID.
Important: When decrypting, what matters is the certificate's fingerprint, not the user ID. There can be multiple certificates with the same name and email address, but only one of them will work.
Why is my (or someone else's) certificate no longer shown as VS-NfD compliant?
In Kleopatra, you might see an OpenPGP certificate marked as not VS-NfD compliant (highlighted in pink). This means the algorithm used does not meet the requirements for handling information classified as Classified – FOR OFFICIAL USE ONLY (VS-NfD).
This warning only appears if the certificate was not created using GnuPG VS-Desktop®.
In most cases, the issue is due to the use of the RSA-2048 algorithm, which lost its VS-NfD approval in early 2024. The ECC algorithms Ed25519 and Curve25519, which are the default choices in Gpg4win, are also currently not approved by the BSI for VS-NfD use.
If, however, you create a key using the ECC algorithm based on the Brainpool curve, the situation is different: this variant is approved for VS-NfD and can be generated directly using GnuPG VS-Desktop®.
How do I detect a certificate's algorithm?
Whether a certificate meets the requirements for VS-NfD depends on the algorithm it uses. You can easily check this yourself.
For OpenPGP certificates:
- In Kleopatra, double-click the relevant certificate.
- Switch to the Subkeys tab.
- In the Algorithm column, you'll see entries like RSA 2048, ECC (Ed25519), or ECC (Cv25519). If the certificate is shown as non-compliant, it's often because of these specific entries.
For S/MIME certificates:
- Double-click the certificate.
- Open the Certificate Dump tab.
- Look for the keyType field. This may show values like rsa4096 (compliant) or rsa2048 (non-compliant).
What does this mean for how certificates appear in Kleopatra? Certificates using a VS-NfD-compliant algorithm are highlighted in light green and labeled VS-NfD Compliant. All others may still be certified but are not compliant; they appear in pink with the status certified.
Root certificates that are trusted are always shown in blue in Kleopatra, regardless of whether they use VS-NfD-compliant algorithms or not. In the Status column, you'll see either VS-NfD compliant or certified.
If the status shows not certified, it means the certificate is not trusted. To use such a root certificate without restrictions, it must be installed and explicitly trusted by an administrator.
S/MIME certificates follow the same rules for VS-NfD compliance as OpenPGP certificates. The deciding factor is the algorithm used.
Why is my own certificate marked as "Not certified"?
If your own OpenPGP certificate shows up as not certified in Kleopatra, the reason is usually a small detail: When importing a backup, you didn't confirm that the certificate belongs to you.
You can easily fix this with just a few clicks: Right-click the entry and select Change Certification Power.
Helpful to know: Kleopatra displays your own public keys (certificates) with a corresponding private key in bold.
Why does encryption fail with "Unusable public key"?
This error message appears when you try to encrypt to a Kleopatra group that contains at least one certificate which wasn't properly renewed.
A common case: The certificate had expired and was extended using Kleopatra (up to and including GnuPG VS-Desktop® 3.1.26), but only partially. At first glance, everything seems fine: the certificate is marked as valid. But behind the scenes, the encryption subkey hasn't been renewed, making the certificate unusable for encryption. (Ticket T6473)
Solution: The person whose certificate is affected needs to manually extend the subkey.
Here's how to do it:
1. In Kleopatra, open the certificate list and double-click your certificate.
2. In the new window, click More Details in the lower-left corner.
3. The detail view now shows two lines: The first (for the signing subkey) says valid, the second (for the encryption subkey) says expired.
4. Right-click the second line and choose Change validity from the context menu.
5. Now set the same expiration date as shown in the first line and confirm by clicking OK.
6. Both subkeys now share the same expiration date, and the certificate is fully usable again. Everything should work as expected.
7. Do a quick test, and encrypt a file or message to yourself. If it works, you're good to go.
8. Finally, export the updated certificate and share it with your communication partners. This ensures they can see and use the new validity period as well.
Why isn't my certificate available for encryption after renewal?
At first glance, the certificate looks perfectly fine, and it appears as valid in the certificate list. However, it doesn't show up when encrypting a file or in Outlook.
This happens when an expired certificate was renewed using Kleopatra from GnuPG VS-Desktop® (version 3.1.26 or earlier), but not completely.
Why can’t I select a recipient for file encryption?
If you can't select any recipients in the file encryption dialog, it's usually due to a setting in Kleopatra. The recipient field appears grayed out because Kleopatra is set to use symmetric encryption only.
To fix this, open the settings and go to the Crypto Operations tab. Check if the option Use symmetric encryption only is enabled.
Uncheck the box to enable recipient selection again.
Password-Based Encryption
Why does decryption fail with "Bad passphrase"?
You entered an incorrect password or accidentally copied an extra character like a space. Please double-check your input and make sure capitalization matches exactly.
If the password was generated by GnuPG VS-Desktop®,
it consists of exactly 30 characters from the following set:
13456789abcdefghijkmnopqrstuwxyz (For readability, the characters 0,
2, l, and v are not included.)
Important: These passwords may be shown with spaces to improve readability. Do not include the spaces when entering the passphrase.
GpgOL Questions
What does "Not all attachments can be shown" mean?
When opening an encrypted email, GpgOL may display the message Not all attachments can be shown. This behavior is typically caused by the internal handling of messages within the add-on: When decrypting, GpgOL retains the original encrypted message and attaches the decrypted version to the same mail object. As a result, the email size temporarily doubles.
If this size exceeds the maximum message limit configured on the Exchange server, GpgOL displays only as many attachments as technically possible. The rest are suppressed, and the above message is shown.
The encryption method also plays a role:
- S/MIME messages are not compressed, so they reach the limit more quickly.
- OpenPGP messages use compression and are generally smaller.
Workaround: Save the affected email via drag & drop to your local file system and open it using Windows Explorer. This allows the message to be decrypted outside of Outlook.
If this issue occurs frequently, you may consider increasing the message size limit on your Exchange server.