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:
--> 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
--> 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
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)
--> Testing (perfect) forward secrecy, (P)FS -- omitting 3DES, RC4 and Null Encryption
Not OK: No ciphers supporting Forward Secrecy offered
--> Testing server preferences
Has server cipher order? yes (OK)
Negotiated protocol TLSv1
Negotiated cipher AES256-SHA
SSLv3: AES256-SHA RC4-MD5 RC4-SHA AES128-SHA DES-CBC3-SHA DES-CBC-SHA EXP-RC4-MD5
TLSv1: AES256-SHA RC4-MD5 RC4-SHA AES128-SHA DES-CBC3-SHA DES-CBC-SHA EXP-RC4-MD5
Enterprise Systems Engineer
SD Group: EIT Infrastructure – OMA
From: William Brown [mailto:email@example.com]
Sent: Sunday, January 03, 2016 3:53 PM
To: General discussion list for the 389 Directory server project.
Subject: [389-users] Re: PCI SSL TLS certificate requirements change
On Mon, 2015-12-28 at 17:50 +0000, Mayberry, Alexander wrote:
Hi, we are using SSLv3 certs, and have a multi-master replication
I have over 2000 clients currently using these CAs, and updating them
to TLS seems highly disruptive.
There is no difference between an "SSLv3" and a "TLS" cert. They are
just "certificates" to DS. SSLv3 and TLS are the connection protocols to the
Does anyone know of a way to add the updated TLS cert, while still
honoring the old SSLv3 certs from clients?
Or perhaps a way to add new replicas in to the environment with the
new TLS certs, but also add them in to the replication pool with the
old SSLv3 systems?
Maybe a good guide/white paper on how to achieve this for PCI
So really, what you are doing is certificate rollover. It's a fun / difficult thing to
If you are not changing the signing CA, then you just need to replace the certificates in
a rolling fashion on your DS instances. They will need a restart to take effect, and all
your clients will "just work".
If you are changing the certificate and the CA that signs them, you are in for some fun.
First, you can do what you are suggesting, and make new replicas that run the new certs vs
Say you have A and B now in MMR, you can setup two more replicas, A, B, C, D.
If you make sure the certificate's CA's are on ALL A, B, C, D, you can run
certificates signed by CA1 on A and B, and CA2 on C and D. Then you point the clients
where they need to be.
But that's pretty messy I think. And overly complicated. So please don't do
Best bet is on all your clients to roll out the new CA so they accept
CA1 and CA2. Once you have done this, then you can change over one DS instance out of A
and B, to have the new certificate signed by the new CA. Most clients will work, any that
you have missed will have a 50% of throwning a problem at this point.
Clients that throw an issue, you can point at B in the interim so they work, then you can
update thier ldap CA store to include the new CA, and put them back as connecting to A and
Then you can change over B to the new CA, and repeat the process.
There is really no way around it, but there is a risk when changing CA provider that you
will mess something up.
Finally, if you don't want to mess around that much, you could set TLS_REQCERT=Never,
but I really, really, really don't advise that. Use it as a work around until you can
update the CA bundle.
When I managed a certificate roll over in my past environments, this is what I did,
coordinating with other business units, getting the new CA out, lots of testing in a stage
environment with application etc. Took about 3 months to do all the testing and due
diligence, and pre- loading the new CA, but on the day of the cut over there were no
issues at all.
I hope this helps.
Red Hat, Brisbane