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

[Dr. Thomas Orgis]

Am Mon, 22 Jul 2019 00:44:08 +0200
schrieb Ángel <angel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4984 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190730/481a5f52/attachment-0001.bin>