On 09/23/2015 05:05 PM, Michael Lasevich wrote:
Yes, I am talking about 389ds as is integrated in FreeIPA (would be silly to
post completely non-IPA questions to this list...).

You would not be the first to do it :-)

I am running FreeIPA 4.1.4 on CentOS 7.1 and RC4 is enabled on port 636 no
matter what I do.

I am running "CentOS Linux release 7.1.1503 (Core)"

Relevant Packages:


LDAP setting (confirmed that in error.log there is no menition of RC4 in list
of ciphers):


Something is really strange here. We need to see settings in "cn=encryption,cn=config" to investigate further.

$ ldapsearch -h ipa.example.com -b cn=encryption,cn=config -D "cn=Directory Manager" -x -W

should be a good start to give this information. nsSSL3Ciphers for example should be set to "+all" and "allowWeakCipher" to off, as per


Slapd "error" log showing no ciphersuites supporting RC4:

[23/Sep/2015:08:51:04 -0600] SSL Initialization - Configured SSL version range:
min: TLS1.0, max: TLS1.2
[23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza is not
available in NSS 3.16.  Ignoring fortezza
[23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza_rc4_128_sha is
not available in NSS 3.16.  Ignoring fortezza_rc4_128_sha
[23/Sep/2015:08:51:04 -0600] - SSL alert: Cipher suite fortezza_null is not
available in NSS 3.16.  Ignoring fortezza_null
[23/Sep/2015:08:51:04 -0600] - SSL alert: Configured NSS Ciphers
[23/Sep/2015:08:51:04 -0600] - SSL alert:
[23/Sep/2015:08:51:04 -0600] - SSL alert:
[23/Sep/2015:08:51:04 -0600] - SSL alert:
[23/Sep/2015:08:51:04 -0600] - SSL alert:
[23/Sep/2015:08:51:04 -0600] - SSL alert:       TLS_RSA_WITH_AES_128_CBC_SHA:
[23/Sep/2015:08:51:04 -0600] - SSL alert:       TLS_RSA_WITH_AES_256_CBC_SHA:
[23/Sep/2015:08:51:04 -0600] - 389-Directory/ <>
B2015.040.128 starting up

But sslscan returns:

$ sslscan --no-failed localhost:636

Supported Server Cipher(s):

     Accepted  TLSv1  256 bits  AES256-SHA
     Accepted  TLSv1  128 bits  AES128-SHA
     Accepted  TLSv1  128 bits  DES-CBC3-SHA
     Accepted  TLSv1  128 bits  RC4-SHA
     Accepted  TLSv1  128 bits  RC4-MD5
     Accepted  TLS11  256 bits  AES256-SHA
     Accepted  TLS11  128 bits  AES128-SHA
     Accepted  TLS11  128 bits  DES-CBC3-SHA
     Accepted  TLS11  128 bits  RC4-SHA
     Accepted  TLS11  128 bits  RC4-MD5
     Accepted  TLS12  256 bits  AES256-SHA256
     Accepted  TLS12  256 bits  AES256-SHA
     Accepted  TLS12  128 bits  AES128-GCM-SHA256
     Accepted  TLS12  128 bits  AES128-SHA256
     Accepted  TLS12  128 bits  AES128-SHA
     Accepted  TLS12  128 bits  DES-CBC3-SHA
     Accepted  TLS12  128 bits  RC4-SHA
     Accepted  TLS12  128 bits  RC4-MD5


I would assume the sslscan is broken, but nmap and other scanners all confirm
that RC4 is still on.


On Wed, Sep 23, 2015 at 3:35 AM, Martin Kosek <mko...@redhat.com
<mailto:mko...@redhat.com>> wrote:

    On 09/23/2015 11:00 AM, Michael Lasevich wrote:
     > OK, this is most bizarre issue,
     > I am trying to disable RC4 based TLS Cipher Suites in LDAPs(port 636) and
     > for the life of me cannot get it to work
     > I have followed many nearly identical instructions to create ldif file 
     > change "nsSSL3Ciphers" in "cn=encryption,cn=config". Seems simple enough 
     > and I get it to take, and during the startup I can see the right SSL 
     > Suites listed in errors.log - but when it starts and I probe it, RC4
     > ciphers are still there. I am completely confused.
     > I tried setting "nsSSL3Ciphers" to "default" (which does not have "RC4")
     > and to old style cyphers lists(lowercase), and new style cypher
     > lists(uppercase), and nothing seems to make any difference.
     > Any ideas?
     > -M

    Are you asking about standalone 389-DS or the one integrated in FreeIPA? As
    with currently supported versions of FreeIPA, RC4 ciphers should be already
    gone, AFAIK.

    In RHEL/CentOS world, it should be fixed in 6.7/7.1 or later:


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to