Duo Authentication Proxy - ssl_ca_certs_file Does Nothing?

I recently set up a Duo Authentication Proxy server.
The primary authentication server supports plain authentication only, so I had to establish ldaps (or starttls) for the transport.
To do that, I have to set ssl_ca_certs_file to a path pointing to the PEM-encoded certificate from the server.

To do that, I fetched the certs with openssl (openssl.exe s_client -connect our.ldap.server:636 -showcerts), then copied and pasted the various certificate blocks into a text file and pointed ssl_ca_certs_file at that file.

This all worked.

Today, I was working on automating this process, because when that cert is changed out we’d have to update the cert that the ssl_ca_certs_file setting points to. Otherwise Duo wouldn’t work and we’d be locked out of accessing things. At least, that’s what I thought.

In my testing, I found out that ssl_ca_certs_file doesn’t seem to do anything. The connectivity tool will check to see if the file is there (and accessible). It will throw an error if you specify starttls or ldaps for tranport and do not specify ssl_ca_certs_file , and it will throw an error if you specify ssl_ca_certs_file but the file you point to does not exist (or is inaccessible).

It does not seem to check the contents of the file, or check the file against the certificate the server presents.

Similarly, when actually trying to log in, everything works even if ssl_ca_certs_file points to an empty text file, or a text file with random data in it.

Yes, I’m restarting the DuoAuthProxy service after making changes to the ssl_ca_certs_file that Duo is looking at.

Is there something I’m missing?

Hi there!

ssl_ca_certs_file is not supposed to be the target server’s SSL certificate. It should be the certificate (or certificate chain) of the target server’s certificate’s issuing CA, and the proxy uses that CA info to validate the SSL cert presented by the target server during the SSL/TLS handshake.

If you populated the contents with all the certificate blocks from the openssl.exe output, then the entire CA chain in likely represented in your file’s.

If you are swapping out the SSL certificate for your primary authentication server, but the new cert has the same issuer as the previous cert, then there is no need to update the contents of ssl_ca_certs_file when you update the server certificate.

If the new cert has a different issuer, the you would need to update ssl_ca_certs_file.

The only time that ssl_ca_certs_file needs to contain the server SSL cert is when it’s self-signed (and then also would need its contents updated if the cert is changed).

From the Authentication Proxy Reference:

In order to secure LDAP connections to your directory server using LDAPS or STARTTLS protocols, you’ll need the PEM formatted certificate of the certificate authority (CA) that issued your AD domain controller’s or LDAP directory server’s SSL certificate.

Does this information help answer your question?

I wasn’t sure what was needed, exactly, so I copied the whole chain.

Regardless, the file doesn’t seem to do anything. If I create an entirely blank text file and point ssl_ca_certs_file to it, then restart the DuoAuthProxy service, everything still works.

Does Duo perhaps cache the certs elsewhere?

Looks like this was a known security flaw, and it was fixed in 5.1.0 .

Corrected an issue where SSL verification was disabled if an empty or invalid file was provided for ssl_ca_certs_file.

Thanks, Brian, for following up to share what you found with the community! I have marked your reply as the solution to the post, so others might easily find it in the future.