On 2016-01-28 13:51, Roderick Johnstone wrote: > Hi > > My netapp filer is happily doing ldap over ssl lookups for account > information to my RHEL 6.7 testing ipa server > (ipa-server-3.0.0-47.el6_7.1.x86_64). > > However, when I switch the filer to use my RHEL 7.2 ipa server > (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work. > > In the dirsrv log file I see entries like this: > > [28/Jan/2016:09:17:45 +0000] conn=1338 fd=112 slot=112 SSL connection > from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy > [28/Jan/2016:09:17:45 +0000] conn=1338 op=-1 fd=112 closed - Cannot > communicate securely with peer: no common encryption algorithm(s). > > (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the ipa > server ip address). > > Looking in the ldap directory for fields with cipher in the name shows a > very different set of nssslenabledciphers between the two ipa-server > versions. > > I wonder if this might be the issue? > > Can the ldap server tell me what ciphers its being requested to use by > the filer?
Yes, it looks like it is the issue. The supported cipher suites were hardened a while ago. The ticket https://fedorahosted.org/freeipa/ticket/4395 contains more information. During the TLS handshake the client sends a list of supported cipher suites to the server. The server also has a list of supported cipher suites. But the server never sends this list to the client. Instead it picks one common cipher suite (usually the most secure) from the common set of cipher suites. I don't know if you can get 389 DS to print the cipher suites. But you can snoop the ciper suites from the TLS handshake with wireshark or tshark. The handshake isnt't encrypted and can be captures on either the host or the server. # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port ldaps Christian
Description: OpenPGP digital signature
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project