The DFN-PKI has re-issued its own certificate and all the hundreds of
certificates of its sub-CAs, switching from SHA-1 hashes to SHA-2 hashes due to
a requirement by Microsoft, see https://www.pki.dfn.de/faqpki/faqpki-sha2/ (in
German). Because only hash method and validity have been changed, the gpgsm "key
grip" did not change.
This breaks gpgsm if both old and new certificate of any of these CAs are in the
key ring. When e.g. signing an e-mail, dirmngr is called to check CRLs. dirmng
sends an SENDCERT inquiry back to gpgsm to get the certificate of the CA.
dirmngr[12092.0]: no CRL available for issuer id
gpgsm: certificate not found: Ambiguous name
dirmngr[12092.0]: assuan_inquire(SENDCERT) failed: IPC call has been cancelled
dirmngr[12092.0]: error fetching certificate by subject: No data
dirmngr[12092.0]: crl_parse_insert failed: Missing certificate dirmngr[12092.0]:
crl_cache_insert via DP failed: Missing certificate
dirmngr[12092.0]: command ISVALID failed: Missing certificate
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Not found
gpgsm: can't sign using `&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436': Not found
The error "Ambiguous name" is set in gnupg-2.0.22/sm/certlist.c line 543. The
comment at line 518 says:
/* [...] Note, that it is somehwat reasonable to assume that a specification of
a KEYID won't lead to ambiguous names. */
That is now proven to be false by real life.
In the current situation with the DFN-PKI re-issued certificates, it does not
matter whether the old certificate or the new one is returned to dirmngr on this
inquire, but one of them must be returned. I see two possible ways:
1st way: make dirmngr to use the fingerprint instead of the keygrip or any other
string in the SENDCERT inquire.
2nd way: make gpgsm to send the first certificate found on the inquire. (This
would be not so good because there is a chance that the wrong one is returned.)
Because the user has no way at all to avoid that both old and new certificate
get into the keyring, gpgsm/dirmngr must handle this situation gracefully.
I set the priority to critical because this breaks the central webmailers of one
of the biggest universities in Germany.
Issue 1633 might be a duplicate of this issue.