This overloading of "bold" for "my certificates", "qualified certificates" and "trusted root certificates" seems to exist since two decades. I stopped digging into ancient history at the commit that added the hard-coded default filters.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Take care: Too many attributes (color, font) are bad style.
a) "Prefer S/MIME" only applies to encryption, not decryption. If you do not want to decrypt with GpgOL you have to disable S/MIME in GpgOL.
Well, the qual flag should only be set for CAs dedicated to certifying QES certificates. And those should by definition be signature certificates only, afaik.
Fri, Jan 30
Ah, thanks for the pointer, I did not expect gpgsm to behave differently here. Then it's probably intentional and I'll close this as invalid.
The gnupg manual (page 113) mentions:
Thu, Jan 29
Mon, Jan 26
There's no other configuration, this happens with a clean gnupghome with one smime cert + root cert and the above gpgsm.conf (output on stdin/stderr):
Fri, Jan 23
Please run with --debug 0 which should show you which confiration files are read in which order. Is there anything in a common.conf file? A log-file statement tehre would overwrite the command line option.
Wed, Jan 21
setting to High as we need this for T7790
The "ca" root cert is not on the ldap, if that matters
In T8048#211860, @ikloecker wrote:some other certificates, but I guess those are from other tests
It also happens on CLI:
With Gpg4win 5.0.0 the LISTKEYS after the server lookup lists the (ephemeral?) ca@gnupg.test certificate and (!) the bob@gnupg.test certificate (and some other certificates, but I guess those are from other tests).
- VSD 3.3.4
- Gpg4win 5.0.0
Tue, Jan 20
- gpg4win 5.0.0 @ win11
gpgme logs (also of vsd-3.3.4) will be useful.
I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,
Note: This does not happen on vsd-3.3.4
Fri, Jan 16
See the gnupg-devel mailing list for more discussions. Subject: libgcrypt P256 signature malleability via weak DER enforcement"
Wed, Jan 14
Two historic integer encoding glitches from Peter Gutmann's style guide:
Fri, Jan 9
in Gpg4win-5.0.0-beta479
Wed, Jan 7
Traditionally we have considered expired and revoked more or less similar. The idea is that an expired key might have been compromised but the owner did not found a way to revoke it. We may want to change this policy because some users don't care too much about expired keys (cf. T7990) .
>gpgsm -v --sign --local-user "Edward Tester" test.pdf > test.gpg.p7s
gpgsm: enabled compatibility flags:
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: issuer certificate {04A0A7E932B29D43A9B6673139AF52C0A5FC467BF5A64D044D1AC33613ABBB73CA532569F5779999114C0118CD66FDF6E92B1B0EEE2A4D5A815DA7FD892DDDE9C1} not found using authorityKeyIdentifier
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: certificate is good
gpgsm: root certificate is not marked trusted
gpgsm: fingerprint=D4:EC:A6:B4:69:AB:B5:44:08:27:CB:3F:C7:D7:91:08:3C:10:27:DB
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 01
gpgsm: DBG: notBefore: 2020-03-26 19:41:01
gpgsm: DBG: notAfter: 2063-04-05 17:00:00
gpgsm: DBG: issuer: CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE
gpgsm: DBG: subject: CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.11
gpgsm: DBG: SHA1 Fingerprint: D4:EC:A6:B4:69:AB:B5:44:08:27:CB:3F:C7:D7:91:08:3C:10:27:DB
gpgsm: DBG: END Certificate
gpgsm: after checking the fingerprint, you may want to add it manually to the list of trusted certificates.
gpgsm: validation model used: shell
gpgsm: can't sign using 'Edward Tester': Not trusted
[GNUPG:] FAILURE gpgsm-exit 50331649How does gpgsm react if you try to sign with the certificate?
Tue, Jan 6
Maybe it would be better to just not offer S/MIME certs with distrusted root cert?
gpgsm.log (debug-all, whole process of signing)
Dec 12 2025
Nov 19 2025
Nov 16 2025
Fix applied. Thanks.
Nov 14 2025
Nov 6 2025
Oct 9 2025
Might this be related to T4953?
Oct 6 2025
(auto resolved due to the keyword "resolved" in the commit message)
The window was not reenabled on failure see 8d174d5
Oct 2 2025
(removed: wrong statement)
Note: I also activated Sign/Encrypt by default, if that matters
Sep 24 2025
ECC support for X.509 and in particular pkcs#12 format is limited. That is in general not a problem because such certificates are stored on a token and not on disk.
Aug 27 2025
The problem here is that we don't have the sha-2 fingerprint in our SQL tables. Thus we would not only need to do a full table search but also parse the actual blob to compute the sha-2 fingerprint.
I have done testing using my QES certificate with all combinations of the two options.
Jul 25 2025
Jul 24 2025
This does not happen with gnupg24 because the cache has not been implemented there.
Jul 2 2025
May 13 2025
Meanwhile we have some support for an empty subject but gpgsm still prints an error notice. See the T7171 for more.
Apr 22 2025
BTW, fingerprints for X.509 are not well defined because you get a different one when changing the *unsigned" attributes. Not a common case but one should be aware of it.
Feb 18 2025
Jan 24 2025
If you encounter real world certificates with these parameters we can bump up the priority.
Jan 19 2025
I think I can understand you, too much complexity.
Jan 17 2025
See this comment which is related to T4538:
Jan 7 2025
Also works in VSD-beta-478
Dec 19 2024
Dec 16 2024
Dec 11 2024
Oct 29 2024
Oct 4 2024
Test on a dedicated Windows box (T 460, i5-6300U@2.40GHz, harddisk):
| VSD Version | gpg version | Load time |
| 3.1.26 | 2.2.41 | 1:59 |
| 3.2.4 beta-2 | 2.2.45 beta 25 | 0:46 |

