Document signing using a Windows CA

[Tomas28417239pvgz]

Good day,

in our company we sign pdf documents with certificates that are seen by our CA. A document signed in this way has a problem verifying revoked certificates. A document opened in Adobe Reader reports the error "CRL download error Locatino ldap:///..."
Why am I getting this error?
Thank you for answer

[ls_rbls]

Hi,

Did you mean to say that you sign pdf documents that are managed and issued  by a certificate authority (CA) from within your organization?

Based on the little technical specs that you've shared I assume  that an ldap server method is involved to issue certificates and  handle the certificate revocation lists (CRL).

You may need to provide more info.

Meanwhile, what protocol is the ldap server using to revoke or authenticate certificates: SSL or TLS ( which version of TLS: 1.1, 1.2???)

What operating system is the ldap service on?

[Tomas28417239pvgz]

Hi,
yes, the documents are signed by the CA of our organization.
CA runs on Windows Server 2019.
Yes, the ldap server method is involved in issuing certificates and processing certificate revocation lists (CRL).

I'm sorry, but I can't answer which protocol I use, SSL or TLS.

thank you for answer

[Tomas28417239pvgz]

[Tomas28417239pvgz]

CRL download error
Location: ldap:///CN=AD2-CA,CN=ADCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=local,DC=fabrican,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

Cannot connect to server._

[ls_rbls]

Seems like a few steps were missed when the ldap server was configured.

See the Microsoft support  link below. It shows in detail how to properly configure LDAP on a Windows Server 2012 but the steps should be similar for 2019 version:

• https://techcommunity.microsoft.com/t5/sql-server-blog/step-by-step-guide-to-setup-ldaps-on-windows-...

If you scroll down almost to the end of that article, it shows how to test for a connection with or without Secure Sockets Layer (SSL) encryption protocol.

Also check the port numbers or sockets that the clients will be connecting to.

In addition,see this other more in-depth Microsoft support guidance:

• https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-signing-in-window...

Specifically these links:

• https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-cert...

• https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/ldap-over-ssl-connection-issu...

[Tomas28417239pvgz]

Ldap on SSL is OK:

[Tomas28417239pvgz]

Also verifying CDP certificate revocation with certutil seems to be fine.

[ls_rbls]

I forgot to ask if the error that you posted initially is happening at the client side (i.e. when a user is requesting credential authorization(s)?

Based off of your screenshots, when you said that you have Windows Server 2019 I couldn't help but notice in your logs that there appears to be other older servers in the mix (Windows 2012 and 2016).

Both of these server versions being old you, may want to check if the the CA is actually requiring a different protocol like TLS, and rule out if the problems is triggered because of  those servers are pushing out  deprecated versions of SSL.

Nevertheless, from what I am reading modern web browsers have dropped support for SSL. TLS version protocols are  newer more secured versions of SSL.

The main observation here is that there are about 5 basic steps involved when a client is requesting LDAP authentication; in which the last step is notifying the client back for user access ( granted or denied).

This error that your LDAP client is getting: "CRL download error Locatino ldap:///..." is indicating some sort of misconfiguration at the very early stages of the ldap binding process.

For example,

When the LDAP client initiates a request to bind (or authenticate) with the Active Directory server that is managing the LDAP protocol,  the client receives back a confirmation from that server acknowledging that the authentication has initiated (these handsahking processes cover the first two steps).

The third step is when the LDAP protocol actually do its job.

Not only it checks if such credential(s) exist on whatever LDAP directory you stored them, but it also validates if the binding combinations are correct.

          First possible issue:

• NOTE: Binding strings are case sensitive, see here ==>  https://www.rlmueller.net/LDAP_Binding.htm

         Second possible issue:

• the Active Directory connection(s) are having an issue; your current configuration of the  LDAP protocol is trying to  publish a certificate revocation list (CRL) to an LDAP location that doesn't exist.
  .

The last two steps of this binding operation are basically terminating the binding operation for the LDAP client and granting or denying access.