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
On 2019-07-20 at 20:07 +0200, Dr. Thomas Orgis wrote: > 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) > > (...) > I'd like to have understood first what happened here. 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. 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. ___ 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
Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Hello. Am Donnerstag, den 18.07.2019, 18:33 +0200 schrieb Dr. Thomas Orgis: > Certified by >ID: 0x61A8CF44 >Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > Subject: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust > Center/O=T-Systems Enterprise Services GmbH/C=DE > validity: 2016-04-25 09:01:39 through 2019-07-09 23:59:59 > chain length: unlimited > Certified by >ID: 0x8CDE37BF >Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > Subject: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > validity: 1999-07-09 12:11:00 through 2019-07-09 23:59:00 > chain length: 5 This is the issue here. These two certs of DTAG (Telekom) are exired and that's the reason why gpgsm is complaining correctly. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
