Mailing List Archive

S/MIME certificates with LDAP-only CRL uri
Hello,

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

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>

It only works if I disable CRL checking with option
--disable-crl-checks, which is not such a good idea, I guess.

The CA provides only an LDAP URI for getting the revocation list. Root and
intermediate certificates can be downloaded here:

https://www.dgn.de/dgncert/downloads.html

`gpgsm --dump-chain' presents me the following URI:

crlDP: ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?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. 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.

Alex

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: S/MIME certificates with LDAP-only CRL uri [ In reply to ]
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.

> 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.

> 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.

Regards,
Ingo
Re: S/MIME certificates with LDAP-only CRL uri [ In reply to ]
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

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: S/MIME certificates with LDAP-only CRL uri [ In reply to ]
On Thu, 23 Feb 2023 11:22, Alexander Grahn said:
> Should an ldap host answer on ping requests in general? Because the one in

Pinging arbitrary servers does often work because too many admins tend
to block ICMP echo. An LDAP server is commonly behind some load
balancer and thus a ping won't help you anyway.

> question, ldap.dgnservice.de, remains silent. I tried with other hosts picked

Works for me.

$ dirmngr --debug network --fetch-crl 'ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?objectClass=cRLDistributionPoint'

dirmngr[27784.0]: dirmngr_ldap[27786]: found attribute 'certificateRevocationList;binary'
dirmngr[27784.0]: update times of this CRL: this=20230222T230000 next=20230324T230000
dirmngr[27784.0]: locating CRL issuer certificate by authorityKeyIdentifier
dirmngr[27784.0]: DBG: find_cert_bysubject: certificate not in cache
dirmngr[27784.0]: DBG: get_cert_local_ski called w/o context

Thus it could read the CRL (see the update times) but for verification a
certificate is missing. That is a problem with the fetch-crl command of
dirmngr. I will closer at the problem and thus I need to improve the
error reporting.


Shalom-Salam,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: S/MIME certificates with LDAP-only CRL uri [ In reply to ]
On Thu, Feb 23, 2023 at 04:09:31PM +0100, Werner Koch wrote:
> On Thu, 23 Feb 2023 11:22, Alexander Grahn said:
> > Should an ldap host answer on ping requests in general? Because the one in
>
> Pinging arbitrary servers does often work because too many admins tend
> to block ICMP echo. An LDAP server is commonly behind some load
> balancer and thus a ping won't help you anyway.
>
> > question, ldap.dgnservice.de, remains silent. I tried with other hosts picked
>
> Works for me.
>
> $ dirmngr --debug network --fetch-crl 'ldap://ldap.dgnservice.de:389/CN=CRL-1,O=DGN%20Service%20GmbH,C=DE?certificateRevocationList?base?objectClass=cRLDistributionPoint'
>
> dirmngr[27784.0]: dirmngr_ldap[27786]: found attribute 'certificateRevocationList;binary'
> dirmngr[27784.0]: update times of this CRL: this=20230222T230000 next=20230324T230000
> dirmngr[27784.0]: locating CRL issuer certificate by authorityKeyIdentifier
> dirmngr[27784.0]: DBG: find_cert_bysubject: certificate not in cache
> dirmngr[27784.0]: DBG: get_cert_local_ski called w/o context
>
> Thus it could read the CRL (see the update times) but for verification a
> certificate is missing. That is a problem with the fetch-crl command of
> dirmngr. I will closer at the problem and thus I need to improve the
> error reporting.

Thank your for your reply. Does it mean that the problem is to be solved on the
GnuPG end?

Alexander

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: S/MIME certificates with LDAP-only CRL uri [ In reply to ]
On Thu, 23 Feb 2023 18:37, Alexander Grahn said:

> Thank your for your reply. Does it mean that the problem is to be solved on the
> GnuPG end?

I can't tell because I do not have a valid DGN certificate anymore.
Feel free so send me yours by PM - makes debugging easier.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: S/MIME certificates with LDAP-only CRL uri [ In reply to ]
Hi!

I spent some time looking into this. The CRL is issued by a certificate

CN=dgnservice CRL2101 13:PN,O=DGN Deutsches Gesundheitsnetz Service GmbH,C=DE

However that certificate is not available: I only found the previous one:

ldapsearch -H ldap://ldap.dgnservice.de:389 -b 'O=DGN Deutsches Gesundheitsnetz Service GmbH,C=DE' -x -v -LLL "CN=dgnservice CRL2101 12:PN"

without the certificate we can't verify the CRL. Switching to OCSP does
also not work due to a missing certificate.

We have seen this problem already last year; see
https://dev.gnupg.org/rG90caa7ad598be123707f4d4651f9a64a74347626

Alexander: Maybe you can to ask DGN why they don't distribute that cert
but announce it in the CRL.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein