William, we plan to have RH Engineers come on site to help with the planning/deployment of RHDS. I'm planning to use RHEL7 and whatever the latest RHDS version is, unless someone tells me of some reason why an older version would be better suited. I need to get my head around what actually needs to happen before they arrive, and hopefully minimize the time it takes for them to explain things to me. If it makes sense to wait for this event, and ensure the new RHDS systems are up to spec, and leave the existing systems alone until they are decommissioned, that's a very clean and manageable way to proceed in my view. Thanks for your insight, and info, I appreciate it. Alexander Mayberry Enterprise Systems Engineer SD Group: EIT Infrastructure – OMA Enterprise.Systems Engineering.Infrastructure -----Original Message----- From: William Brown [mailto:wibrown@xxxxxxxxxx] Sent: Thursday, January 07, 2016 5:09 PM To: General discussion list for the 389 Directory server project. Subject: Re: PCI SSL TLS certificate requirements change On Thu, 2016-01-07 at 22:49 +0000, Mayberry, Alexander wrote: > Thanks, William. > I had missed this reply last week. > > We will be switched from 389DS to RHDS sometime in the next few > months, and our audits will start failing us in March if we are still > using sslv3. > > I'd like to address these gaps pro-actively, and minimize the amount > of impact on my client base by allowing a gradual migration of client > systems. > This is why I was asking about adding "secured" systems to the > replication pools, and gradually cutting over the clients. > > If the new RHDS replicas "pass" these tests and are in the replication > pool with the 389ds systems that fail, and I could have our ops teams > schedule batches of client systems to reconfigure, we could process > through this gradually. > > Here's where I'm falling down: You should read: http://www.port389.org/docs/389ds/design/nss-cipher-design.html > --> Testing protocols (via sockets except TLS 1.2 and SPDY/NPN) > > SSLv2 not offered (OK) > SSLv3 offered (NOT ok) > TLS 1 offered > TLS 1.1 not offered > TLS 1.2 not offered (NOT ok) > SPDY/NPN not offered These are controlled in: cn=encryption,cn=config You will likely want to match: nsSSL2: off nsSSL3: off nsTLS1: on Which should give you the output you desire. > > --> Testing ~standard cipher lists > > Null Ciphers offered (NOT ok) > Anonymous NULL Ciphers not offered (OK) > Anonymous DH Ciphers not offered (OK) > 40 Bit encryption offered (NOT ok) > 56 Bit encryption Local problem: No 56 Bit encryption > configured in /usr/bin/openssl > Export Ciphers (general) offered (NOT ok) > Low (<=64 Bit) offered (NOT ok) > DES Ciphers offered (NOT ok) > Medium grade encryption offered (NOT ok) > Triple DES Ciphers offered (NOT ok) > High grade encryption offered (OK) > Here you probably want to look at: nsSSL3Ciphers: default allowWeakCipher: off Specfically, you may actually want to customise this list such as: nsSSL3Ciphers: +tls_dhe_rsa_aes_128_gcm_sha,+tls_dhe_rsa_aes_128_sha,+tls_dhe_rsa_aes_ 256_sha,+tls_rsa_aes_128_gcm_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_ sha You may need to adapt this list with the new NSS cipher suite names rather than the hardcoded directory values. However, reading that document it states that if you have 389-ds-base 1.3.3 or greater, setting "nsSSL3Ciphers: default", will give you a very strong cipher list by default. > --> Testing (perfect) forward secrecy, (P)FS -- omitting 3DES, RC4 > and Null Encryption here > > Not OK: No ciphers supporting Forward Secrecy offered > > > --> Testing server preferences > > Has server cipher order? yes (OK) > Negotiated protocol TLSv1 > Negotiated cipher AES256-SHA > Cipher order > SSLv3: AES256-SHA RC4-MD5 RC4-SHA AES128-SHA DES-CBC3-SHA > DES-CBC-SHA EXP-RC4-MD5 EXP-RC2-CBC-MD5 > TLSv1: AES256-SHA RC4-MD5 RC4-SHA AES128-SHA DES-CBC3-SHA > DES-CBC-SHA EXP-RC4-MD5 EXP-RC2-CBC-MD5 See above, May I ask what version of RHDS you plan to deploy, and on what version of RHEL? I hope this helps you resolve your issue. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
