Could you help me understanding how to configure 389-ds to enable CRL checking at TLS
authentication ?
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
ignored.
By checking the source code of 389-ds-base, I found the configuration item
"nsslapd-tls-check-crl".
I set this item to "peer" mode in order to check the CRL referenced in the
received certificate.
Note: This option is not described in the "Configuration, Command, and File
Reference" documentation.
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
certificate CRL))
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 1.3.7.5 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
history.
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.
Thanks.
_______________________________________________
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
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia