Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Am Tue, 30 Jul 2019 13:28:32 +0200 schrieb "Dr. Thomas Orgis" : > And even with it present, is it > correct behaviour for gpgsm to consider the chain invalid instead of > just the cross-signature? It _does_ trust the new root cert already … > no need for any further signature. Just now the third colleague (all people working at German universities) contacted me about having even a more persisting variant of this issue, with the old root cert cross-signature being re-imported by gpgsm and thus practically permanently breaking the use of the new certificate. Can we consider this a bug in gpgsm's handling of signatures or is this really working as designed? Regards, Thomas > PS: Just for fun, I'm trying to sign this post now. Maybe it won't even > be broken by the list? The list does break the signature. I'm not adding one now … -- Dr. Thomas Orgis HPC @ Universität Hamburg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Am Mon, 22 Jul 2019 00:44:08 +0200 schrieb Ángel : > Well, it seems that «T-TeleSec GlobalRoot Class 2» was cross-signed by > «Deutsche Telekom Root CA 2». > This is typically done with new roots so that people with an older set > of roots can trust it through an older one. Right. But if this is standard procedure … > Now, your problem is that the old Root CA expired and your client is not > able to find the new trust path. > I would probably try deleting the T-TeleSec GlobalRoot Class 2 and > reimporting it from the root, to see if that helps. … why does it lead to this situation? I now simply deleted the offending cross-certificate via gpgsm --delete-key 0x61A8CF44 and now gpgsm happily accepts the new root cert. So, removal of an expired signature makes the chain valid. Shouldn't gnupg the just ignore the expired signature? I went further now, deleting the root cert itself: gpgsm --delete-key 0x17D894E9 But I figure that this does not matter at all, as dirmngr has it. I now fail to understand where the cross-signature came from. I don't see it in the certificate file I exported from Firefox (browser-based certification process). I don't see it in the root certificate file that is offered separately for download. As I still have a backup of my .gnupg folder, can I trace where the cross-signature entered the picture? And even with it present, is it correct behaviour for gpgsm to consider the chain invalid instead of just the cross-signature? It _does_ trust the new root cert already … no need for any further signature. Regards, Thomas PS: Just for fun, I'm trying to sign this post now. Maybe it won't even be broken by the list? -- Dr. Thomas Orgis HPC @ Universität Hamburg smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Am Sat, 20 Jul 2019 20:07:37 +0200 schrieb "Dr. Thomas Orgis" : > The issue I see is that > these certs are not even supposed to be in the chain! > the presence of the old certificates stirs things up. When I create a > fresh user and import the new key with its certs into gpgsm, the chain > looks like it should. Shall I open a bug report about this behaviour? Any investigation I could do to make the report more useful? Regards, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Hi, thanks for looking at this … am Sat, 20 Jul 2019 11:01:49 +0200 schrieb Dirk Gottschalk : > This is the issue here. These two certs of DTAG (Telekom) are exired > and that's the reason why gpgsm is complaining correctly. Please check again my original post, though. The issue I see is that these certs are not even supposed to be in the chain! To repeat the summary, which may be lost in the noise before it: The chain in the imported new key & cert file how it should be: 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by T-TeleSec GlobalRoot Class 2 (root) Compared to what gpgsm sees/shows: 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by Deutsche Telekom Root CA 2 0. Deutsche Telekom Root CA 2 signed by Deutsche Telekom Root CA 2 (expired root) The bogus signatures by the old Telekom certificates appear only after importing in gpgsm, and colleagues using the same kind of certificates use them without problem in software not relying on gpgsm. So I assume the presence of the old certificates stirs things up. When I create a fresh user and import the new key with its certs into gpgsm, the chain looks like it should. /home/tester/.gnupg/pubring.kbx --- ID: 0x310C60AF Issuer: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=Thomas Orgis/OU=HPC/OU=Basis-Infrastruktur/OU=RRZ/O=Universitaet Hamburg/L=Hamburg/ST=Hamburg/C=DE validity: 2019-07-05 08:22:41 through 2022-07-04 08:22:41 Certified by ID: 0xD9463C45 Issuer: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-05-24 11:38:40 through 2031-02-22 23:59:59 chain length: 1 Certified by ID: 0xD3A89A93 Issuer: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE Subject: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-02-22 13:38:22 through 2031-02-22 23:59:59 chain length: 2 Certified by ID: 0x17D894E9 Issuer: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE Subject: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE validity: 2008-10-01 10:40:14 through 2033-10-01 23:59:59 chain length: unlimited So this looks like a corruption in my keyring that includes the history of using gpgsm for about 5 years:-/ I now could play games with exporting keys and starting with a fresh database … but I'd like to have understood first what happened here. Regards, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by Deutsche Telekom Root CA 2 0. Deutsche Telekom Root CA 2 signed by Deutsche Telekom Root CA 2 (expired root) How come? I tried to forcedly import the new root cert into gpgsm, but it tells me it has it stored already. shell$ LANG=C gpgsm --import rootcert2019.crt gpgsm: enabled debug flags: ipc gpgsm: total number processed: 1 gpgsm: unchanged: 1 secmem usage: 0/16384 bytes in 0 blocks So it looks to me as if gpgsm somehow constructs a wrong certificate chain. Is this a known problem? Did I do something wrong? Regards, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Behaviour of gpgsm / gpgme with multiple S/MIME certificates/keys per address (old/expired/about to expire and new)
Am Fri, 9 Jun 2017 14:17:24 +0200 schrieb "Dr. Thomas Orgis" <thomas.or...@uni-hamburg.de>: > But after that, claws-mail as well as gpgsm complain about > the keys being ambiguous. Clearly, the call No takers? I am the only one getting a fresh S/MIME cert? I now modified claws-mail to add preferences to each mail account for separate PGP and S/MIME key choise and set the correct keys there. I still wonder if that is the right approach or if there is a way to convince gpgme to decide about the best key to use (clearly where all others are expired). Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg RRZ / Basis-Infrastruktur / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270 smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Behaviour of gpgsm / gpgme with multiple S/MIME certificates/keys per address (old/expired/about to expire and new)
Hi, I recently got into trouble with S/MIME signing and encryption in claws-mail, which uses gpgme. My old (first) S/MIME certificate is about to expire, so I got a new one. I added the new one to gpgsm's keystore. But after that, claws-mail as well as gpgsm complain about the keys being ambiguous. Clearly, the call gpgsm -u u...@example.com aborts because it cannot decide which of the two certificates to use. It works when I specify a definite key ID (fingerprint) for -u or just fix the default one. But what if I have multiple mail addresses, each with old and new keys lying around? Is there a way to tell gnupg to prefer a certain key for a given mail address? While I can fix a key ID in claws-mail, too, this currently breaks altenating usage of S/MIME and PGP, as currently there is only one configuration field for the key ID to use for both (hopefully that will change soon). With the GPG/PGP part, I revoke my old key and all seems fine. I somehow fail to see the equivalent mechanism for S/MIME. I even checked the expiration process, advancing my system clock past the expiration date of the old certificate. Even then, gpgsm complained about ambiguous keys. Wouldn't it be sensible to a) always use the newest S/MIME key with non-expired certificate and b) discard the ones that are expired by default? This issue even extended to antoher installation of gnupg/claws-mail suddenly refusing to use the old key, although I did not yet add the new secret key to it. They just picked up on the new certificate being published and hence also consider the keys ambiguous (even if there is only one secret key). Any pointers? I wonder if I am doing something basic wrong, as regular expiration of S/MIME certificates is the norm, isn't it? Doesn't anyone else have issues with the accumulating number of old certificates? (I am using GnuPG 2.1.21, gpgme 1.9.0., btw.) Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg RRZ / Basis-Infrastruktur / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270 smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
