Mailing List Archive

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