Mailing List Archive

Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Hi,

I'm trying to switch to my third S/MIME cert after two earlier expired
ones in gpgsm. The private key and the certificate are valid into the
year 2022, but gpgsm (version 2.2.15) tells me this:

shell$ LANG=C gpgsm --sign -u 0x310C60AF
[…]
gpgsm: certificate is good
gpgsm: intermediate certificate is good
gpgsm: intermediate certificate is good
gpgsm: intermediate certificate has expired
gpgsm: (expired at 2019-07-09 23:59:59)
gpgsm: root certificate is good
gpgsm: DBG: chan_4 -> ISTRUSTED 85A408C09C193E5D51587DCDD61330FD8CDE37BF
gpgsm: DBG: chan_4 <- OK
gpgsm: root certificate has expired
gpgsm: (expired at 2019-07-09 23:59:00)
gpgsm: policies not checked due to --disable-policy-checks option
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: validation model used: shell
gpgsm: can't sign using '0x310C60AF': Certificate expired
secmem usage: 0/16384 bytes in 0 blocks

It thinks my fresh certificate is expired. Looking at the certificate
chain, there is some weirdness (some lines trimmed):

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
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: 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

Instead of ending with the correct root cert named T-TeleSec GlobalRoot
Class 2, there is some cross-signing with the expired Telekom
certificates. These signatures themselves look bogus. Colleagues using
the same sort of certificates do not have this issue. It seems I am the
only one using the GnuPG S/MIME implementation (with Claws Mail) and
people give me stange looks as a weirdo among weirdos (normal weirdos
use Thunderbird with it's builtin S/MIME or mutt, both of which seem to
work fine here).

Looking at the source of the key and certs: I got a pkcs12 file
exported from Firefox (that I just `gpgsm --import`ed), and a
conversion of that via openssl shows these contained signatures:

$ grep -e subject -e issuer mycert3.pem
subject=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
issuer=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
subject=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
issuer=C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
subject=C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
issuer=C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
subject=C = DE, ST = Hamburg, L = Hamburg, O = Universitaet Hamburg, OU = RRZ, OU = Basis-Infrastruktur, OU = HPC, CN = Thomas Orgis
issuer=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA

So, you see the chain

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:

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)

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: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm [ In reply to ]
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
Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm [ In reply to ]
Hi,

thanks for looking at this …

am Sat, 20 Jul 2019 11:01:49 +0200
schrieb Dirk Gottschalk <dirk.gottschalk1980@googlemail.com>:

> 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 [ In reply to ]
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 [ In reply to ]
Am Sat, 20 Jul 2019 20:07:37 +0200
schrieb "Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>:

> 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 [ In reply to ]
Am Mon, 22 Jul 2019 00:44:08 +0200
schrieb Ángel <angel@pgp.16bits.net>:

> 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