Page MenuHome GnuPG

Fresh certificate get's pulled into certificate chain with expired root certificate
Closed, ResolvedPublic

Description

Hi,

i have the same problem described as in this post on the mailing list. Unfortunately, the deleting of the expired root certificate is only a short-time solution in my setup. This is because by reading old emails, my email client pulls the old root certificate so it could check the expired signatures from an email from a few years ago.

PROBLEM DESCRIPTION
My certificate gets pulled into the expired chain if the expired certificate exits.

The correct chain is as follows (please see the attachments for more details on the chain):

  1. Denis Stogl (me) signed by KIT-CA
  2. KIT-CA signed by DFN-Verein Certification Authority 2
  3. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2
  4. T-TeleSec GlobalRoot Class 2 signed by T-TeleSec GlobalRoot Class 2 (root)

The wrong chain:

  1. Denis Stogl (me) signed by KIT-CA
  2. KIT-CA signed by DFN-Verein Certification Authority 2
  3. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2
  4. T-TeleSec GlobalRoot Class 2 signed by Deutsche Telekom Root CA 2 (expired)
  5. Deutsche Telekom Root CA 2 signed by Deutsche Telekom Root CA 2 (expired)

The concrete problem is that at step 3 to 4, gpgsm is using expired "T-TeleSec GlobalRoot Class 2" in the chain instead of the current one. If I delete expired certificates "T-TeleSec GlobalRoot Class 2" or "DFN-Verein Certification Authority 2" and import my private key again, the chain gets correct, and the current "T-TeleSec GlobalRoot Class 2" is used in the chain.

Do you have any idea what is happening here? Please look at the discussion on the mailing list because there are some ideas about the problem.

Thanks and cheers,

Denis

See P9 for samples (user account required)

Details

Version
2.2.4 on Ubuntu 16.04

Related Objects

Event Timeline

werner added projects: S/MIME, gnupg (gpg22).
werner added a subscriber: werner.

Thanks for the sample certs. I noticed the posts but had not the time to look into them.

werner lowered the priority of this task from High to Normal.Nov 7 2019, 3:18 PM
werner moved this task from Backlog to For next release on the gnupg (gpg22) board.

Sorry, a fix didn't made it into 2.2.18.

It would be helpful if you could send me the actual certificates; I realized too late that the attached files had only the list of certificates. In particular, I do not know from where to get the expired certificate.

destogl changed the visibility from "Public (No Login Required)" to "All Users".

I uploaded the certificate files. For a test please do the following:

  1. Import new_key.pem
  2. If needed, import new_chain.pem (it could be that is pulled automatically)
  3. Now everything looks good
  4. Import old_chain_short.pem
  5. Now the "new_key" ends up int the old chain.

I found a solution for master and 2.1.19 which minimizes the risk of regressions:

/* We need to consider some corner cases.  It is possible that we
 * have a long term certificate (e.g. valid from 2008 to 2033) as
 * well as a re-issued (i.e. using the same key material) short term
 * certificate (say from 2016 to 2019).  Using the short term
 * certificate is the proper solution.  But we need to take care if
 * there is no re-issued new short term certificate (e.g. from 2020
 * to 2023) available.  In that case it is better to use the long
 * term certificate which is still valid.  The code may run into
 * minor problems in the case of the chain validation mode.  Given
 * that this corner case is due to non-diligent PKI management we
 * ignore this problem.  */

Note that dirmngr uses simpler code for validating the certificate chains for TLS and CRLs. As long as we do not see bug reports for this there won't be any changes to work around, hmm, interesting PKI setups.

werner claimed this task.
werner changed the visibility from "All Users" to "Public (No Login Required)".