S/MIME certificates with LDAP-only CRL uri

[Alexander Grahn]

On Thu, Feb 23, 2023 at 10:35:38AM +0100, Ingo Klöcker wrote:
> On Mittwoch, 22. Februar 2023 16:35:34 CET Alexander Grahn via Gnupg-users
> wrote:
> > recently I obtained a free certificate from DGN (German Health Net) for
> > signing e-mails. I imported the p12 file  with gpgsm into my keybox and
> > added the complete certificate chain to ~/.gnupg/trustlist.txt
>
> You should only add root certificates to the trustlist. It probably doesn't
> harm to add non-root certificates, but it doesn't make much sense and it makes
> the trustlist longer (and thus less easy to manage) than necessary.

Thanks a lot for this, I learned something new.

>
> > When I try to sign or encrypt, I get the following error:
> >
> >   $ gpgsm --armor --sign testfile.txt
> >   gpgsm: certificate not found: No public key
> >   gpgsm: certificate #410FE63506C68DDF/CN=dgnservice CA 2 Type E:PN,O=DGN
> > Deutsches Gesundheitsnetz Service GmbH,C=DE gpgsm: checking the CRL failed:
> > Not found
> >   gpgsm: error creating signature: Not found <GpgSM>
> [...]
> > `gpgsm --dump-chain' presents me the following URI:
> >
> > crlDP:
> > ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certific
> > ateRevocationList?base?objectClass=cRLDistributionPoint
> >
> > Now my question is whether the LDAP server is down, the URI incomplete
> > or wrong, or whether the problem is on the GPG end.
>
> The ldapurl tool can parse the URI:
> ```
> $ ldapurl -H 'ldap://ldap.dgnservice.de:389/
> CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?
> objectClass=cRLDistributionPoint'
> scheme: ldap
> host: ldap.dgnservice.de
> port: 389
> dn: CN=CRL-1,O=DGN Service GmbH,C=DE
> selector: certificateRevocationList
> scope: base
> filter: objectClass=cRLDistributionPoint
> ```
>
> I failed to use the ldapsearch tool to actually query the URI. It always tells
> me "Could not parse LDAP URI(s)=[...]", but I guess I'm just using it wrong.

Should an ldap host answer on ping requests in general? Because the one in
question, ldap.dgnservice.de, remains silent. I tried with other hosts picked
at random from a simple web search, and they all answered on ping. Maybe
ldap.dgnservice.de is simply down. Meanwhile I doubt that DGN is a reliable CA
at all.

> > On the other hand,
> > I cannot imagine that a wrong LDAP URI remains unnoticed by non-GPG
> > users. I know nothing about ldap and how to test such an URI. What can I do?
> >
> > I am using gnupg-2.4.0 and I double checked that it was compiled with
> > ldap support.
>
> Submit a bug report at https://dev.gnupg.org so that this can be tracked
> properly.

At first, the basic availability of the ldap server should be verified, I think.

Thank you again for your help and kind regards