For the support of cross signing certificates, we need to fix our code for certificate validation in:
Sample certificates are available:
https://datatracker.ietf.org/doc/draft-ietf-lamps-samples/
And it is started to be used by Let's Encrypt migration, in September 2021.
https://ravendb.net/articles/how-cross-signing-works-with-x509-certificates
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T5882 Cross signing certificate in X.509 support | ||
| Resolved | • werner | T5639 dirmngr uses the wrong Let's encrypt chain | ||
| Open | None | T5445 gpgsm fails to find path to valid X.509 root when cross-signed intermediate certificate is present | ||
| Open | None | T2972 GPGSM: Chain too long on cross signed certificate | ||
| Resolved | • werner | T6142 On Windows, gpg 2.3.7 thinks the certificates of major keyservers have expired |
I read OpenSSL implementation.
It does NOT implement backtracking.
In openssl/crypto/x509/x509_vfy.c, it has a function find_issuer which does:
Is this no longer a problem, and someone just forgot to close the issue, or is it now uncommon enough to keep it low priority?
This is a group of tasks of dirmngr and gpgsm.
Cross signing certificate for HTTPS was actually used. For dirmngr (certificate for https), it is solved.
For use cases of gpgsm (S/MIME), it is not common to use cross signing certificates. It is not confirmed if fixes done for dirmngr solved the issues of gpgsm or not.