> > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
