Could you help me understanding how to configure 389-ds to enable CRL checking at TLS
I am working on the master/master replication between two instances.
The TLS communication thanks to certificate works without problem but the CRL url is
By checking the source code of 389-ds-base, I found the configuration item
I set this item to "peer" mode in order to check the CRL referenced in the
Note: This option is not described in the "Configuration, Command, and File
After this configuration, each time a TLS communication is initiated, this communication
fails with the following error :
ERR - NSMMReplicationPlugin - bind_and_check_pwp -
agmt="cn=agreement-ldap1-to-ldap2" (ldap2-server:389) - Replication bind with
SIMPLE auth failed: LDAP error -11 (Connect error) (error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed (unable to get
I try to initiate the TLS communication with certificates that do not containt the CRL
url. The communication fails.
I check that the CRL is available thanks to a wget command.
I found a ticket https://bugzilla.redhat.com/show_bug.cgi?id=1541108
indicating a bug on
the CRL management. The reported bug is the same error that I have encountered.
However, this bug is reported as fixed in the 22.214.171.124 version of 389-ds-base and I am
working with the 2.0.1 version of 389-ds (operating system : Opensuse 15.2)
I suppose that more configuration should be performed in my setup.
2.0.1 should have the changes/fixes mentioned by that bug. I can see them in the git
That error is coming from pretty deep inside of NSS at that point, so I'm not sure
that we can effectively add more debugging to show *which* CRL is failing to be retrieved.
I'd say an obvious bug report to open is with redhat.com
against NSS that "unable
to get certificate CRL" should display the failing URL in the message so that we can
then also display it. But it will take some time before that becomes available to us.
You mention you have checked the wgeting the CRL. To confirm:
* You ran the wget on the CRL from on the LDAP server itself and confirmed it.
* Did you wget every CRL for the entire CA chain?
The obvious work around here is to disable CRL processing in the meantime.
Anyway, that's where I'd start.
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia