Showing results for 
Search instead for 
Did you mean: 

Certificate configuration using Windows PKI


We are trying to configure the LDAP proxy, and we keep getting errors about certificates, in particular Auth Proxy was not able to validate the SSL certificate.

We have an internal PKI that all computers get a certificate from. Those certificates are in the pfx format.

We have five domain controllers we want to put behind the ldap proxy. This is what our [ad_client] looks like:


(we really use the FQDN’s for the DC’s, but I can’t use more than 5 url’s in one post)

The first question is what goes in "ssl_ca_certs_file? I followed the directions here: Knowledge Base | Duo Security

It’s talks about exporting cert from your domain controller but which cert? Each domain controller has 5 certificates each of them with server authentication for the intended purposes. Does it matter which cert? And it looks like you can only have one "ssl_ca_certs_file, can you combine all of the export DC certs or are we only able to use one? We’ve tried exporting a cert from all of the DC’s and combining them into one cer file, but that doesn’t seem to work.

In the ldap_server_auto section we have the same questions:


What cert does ssl_key_path and ssl_cert_path refer to? Should this be a cert issued to the computer running the ldap proxy, or is this some other cert?

1 Accepted Solution

Accepted Solutions

What if you drop -clcerts so, openssl pkcs12 -in filename.pfx -nokeys -out cert.pem

The resulting PEM should have your full CA chain in it.

Does that work to let it verify?

Duo, not DUO.

View solution in original post

5 Replies 5

Cisco Employee
Cisco Employee

It should be the CA chain for the certificate used by your domain controller for incoming LDAPS connections. The Authentation Proxy reference info describes it as:

Path to a file containing the CA certificate(s) to be used to validate SSL/TLS connections to your Active Directory server.

- cert issued to the DC
        - CA root issuer of DC cert    <<<<<<<<<< this should be in the ssl_ca_certs_file specified

Or if you have an intermediate CA and a root CA…

- cert issued to the DC
        - Intermediate CA issuer of DC cert   <<<<<<<<<< this should be in the ssl_ca_certs_file specified
        - CA root issuer of intermediate      <<<<<<<<<< this should be in the ssl_ca_certs_file specified too

When there are multiple certs in the CA chain you can just append in the single pem file you specify for ssl_ca_certs_file.

Yes, that is exactly right. This is the cert the proxy will use for inbound LDAPS, and whatever is downstream making the LDAPS connection to the Duo proxy probably needs to trust the issuer of that cert (or have a setting that allows connections when the cert is from an untrusted CA). This should be different contents than ssl_ca_certs_file (from the ad_client section). But, the same CA that issues your DC’s certs could certainly be used to issue the cert you use for inbound LDAPS to the Duo proxy acting as an LDAP server.

Duo, not DUO.

Thanks for the information, unfortunately we still can’t get it working.

We have a pfx certificate from our internal CA. I’ve used openssl and broken the pfx into the private key file and the certificate file. These are the instructions that I followed:

We can extract the private key form a PFX to a PEM file with this command:

openssl pkcs12 -in filename.pfx -nocerts -out key.pem

Exporting the certificate only:

openssl pkcs12 -in filename.pfx -clcerts -nokeys -out cert.pem

Removing the password from the extracted private key:

openssl rsa -in key.pem -out server.key

When I set the newly created server.key and cert.pem file into the autoproxy.cfg it doesn’t compile.

I get:

The Auth Proxy was not able to create an SSL context with the given certificate and private key. It will be unable to use these credentials to create and maintain SSL-based connections such as LDAPS.

The Auth Proxy was not able to validate the SSL certificate at C:\Program Files\Duo Security Authentication Proxy\conf\cert.pem. Ensure that it is the correct and valid SSL certificate file using commands like ‘openssl x509’ and ‘openssl verify’, or a utility like the MMC Snap-in or Duo’s ‘acert.exe’. If your server cert was signed by a CA, ensure that the entire certificate chain (including the root/CA cert and any intermediate certs in between) is present, with your server cert at the top of the PEM file.

When I use any of those verification methods I get:

error 20 at 0 depth lookup: unable to get local issuer certificate
error C:\Program Files\Duo Security Authentication Proxy\conf\cert.pem: verification failed
70150000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto\store\store_register.c:237:scheme=file
70150000:error:80000002:system library:file_open:No such file or directory:providers\implementations\storemgmt\file_store.c:267:calling stat(C:\Program Files (x86)\Common Files\SSL/certs)
70150000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto\store\store_register.c:237:scheme=C
70150000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:crypto\store\store_meth.c:383:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (C : 0), Properties ()

I’m not sure where to go from here.

What if you drop -clcerts so, openssl pkcs12 -in filename.pfx -nokeys -out cert.pem

The resulting PEM should have your full CA chain in it.

Does that work to let it verify?

Duo, not DUO.

That did it! Thank you so much for your help, it is greatly appreciated.


Configuring a certificate using Windows PKI is an important part of any organization’s security infrastructure. The process involves creating and managing digital certificates, which are used to authenticate users, encrypt data, and verify the identity of computers on networks. With Windows PKI, organizations can easily configure their own public key infrastructure (PKI) in order to manage secure communications within their network. This includes configuring certificates for authentication purposes as well as encryption protocols such as SSL/TLS or IPSec. By taking advantage of this technology, businesses can ensure that all communication between systems is secure and private while also providing a high level of trustworthiness for those who access the system.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers
Quick Links