It sounds like there might be a few things going on here. > On 14 Sep 2020, at 23:44, Bryan K. Walton <bwalton(a)leepfrog.com&gt; wrote: > > We have two CentOS 8 directory servers running 389ds. They are setup > with one as a master and the other as a consumer. Both of these servers > use a wildcard GoDaddy SSL cert. The cert has two intermediate certs, > and the root cert. > > Initially, I had both intermediates and the root cert chained in a CA > cert file and I used the cockpit web interface to upload the chained > file, to both directory servers. When you say you uploaded these, do you mean in the 389 cockpit console? Or somewhere else? It's "quite likely" that when the cert + ca are in a chained file, that certutil/nss underneath are ignoring the other intermediates in the process which could explain why the chain isn't being presented properly. You could try adding the CA and each intermediate one at a time, and the TLS lib used by 389 will "work out" the chain for you (no really, it does this).

> When I did this, I was able to connect to both directory servers with > Apache Directory Studio. However, replication was not working. > > openssl s_client -connect showed that each directory server was only > presenting the server cert and the first intermediate. Still, openssl > reported that everything was "OK". But again, replication wasn't working. > During replication, the master was reporting this in the debug logs: > > (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get issuer certificate)) > > In an effort to fix this, I uninstalled the chained intermediate/root > cert file. I then installed both intermediates, individually, and the > the root cert individually. Sure enough, openssl s_client -connect now > showed the full chain (server cert -> intermediate 1 -> intermediate 2 > -> root CA cert). And replication started working! > > However, now, when I try to connect to either directory server with > Apache Directory Studio, I get the following error: > > Error while opening connection > - ERR_04120_TLS_HANDSHAKE_ERROR The TLS handshake failed, reason: Failed to verify certification path: Algorithm constraints check failed on signature algorithm: SHA1withRSA > org.apache.directory.api.ldap.model.exception.LdapTlsHandshakeException: ERR_04120_TLS_HANDSHAKE_ERROR The TLS handshake failed, reason: Failed to verify certification path: Algorithm constraints check failed on signature algorithm: SHA1withRSA The most likely reason for this is that a cert in the chain/path is not up to the standard expected by your client TLS library. You can check with: openssl x509 -in FILE.PEM -noout -text | grep "Signature Algorithm" Signature Algorithm: sha256WithRSAEncryption I think today most TLS libraries expect at least sha256 and 2048 bit certs. It's probably worth checking that all the certs from the CA, intermediates and your server cert are sha256 + 2048 bit or higher. Hope that helps, — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 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...

On 15 Sep 2020, at 22:34, Bryan K. Walton <bwalton(a)leepfrog.com&gt; wrote: On Tue, Sep 15, 2020 at 09:30:28AM +1000, William Brown wrote: > The most likely reason for this is that a cert in the chain/path is not up to the standard expected by your client TLS library. You can check with: > > openssl x509 -in FILE.PEM -noout -text | grep "Signature Algorithm" > Signature Algorithm: sha256WithRSAEncryption > > I think today most TLS libraries expect at least sha256 and 2048 bit certs. > > It's probably worth checking that all the certs from the CA, intermediates and your server cert are sha256 + 2048 bit or higher. Hope that helps, Thanks William! This was indeed the issue. We were using an older intermediate with sha1. Changing that has fixed our issue.