PCI SSL TLS certificate requirements change

[Mayberry, Alexander]

Hi, we are using SSLv3 certs, and have a multi-master replication environment.

I have over 2000 clients currently using these CAs, and updating them to TLS seems highly
disruptive.

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 requirements?

Alexander Mayberry
Enterprise Systems Engineer
SD Group: EIT Infrastructure – OMA
Enterprise.Systems Engineering.Infrastructure

[William Brown]

On Mon, 2015-12-28 at 17:50 +0000, Mayberry, Alexander wrote:
>  Hi, we are using SSLv3 certs, and have a multi-master replication
>  environment.
>  
>  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 directory server.

>  
>  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
>  requirements? 
So really, what you are doing is certificate rollover. It's a fun /
difficult thing to do.

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 the old:

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 this. 

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 B.

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.

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[Mayberry, Alexander]

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:
--> 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
/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)

--> 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


Alexander Mayberry  
Enterprise Systems Engineer
SD Group: EIT Infrastructure – OMA
Enterprise.Systems Engineering.Infrastructure


-----Original Message-----
From: William Brown [mailto:[e-mail]] 
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 
>  environment.
>  
>  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
directory server.

>  
>  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 
>  requirements?
>  
So really, what you are doing is certificate rollover. It's a fun / difficult thing to
do.

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
the old:

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
this. 

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
B.

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.

--
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[William Brown]

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

[Mayberry, Alexander]

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:[e-mail]] 
Sent: Thursday, January 07, 2016 5:09 PM
To: General discussion list for the 389 Directory server project.
Subject: [389-users] 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

[William Brown]

On Fri, 2016-01-08 at 15:40 +0000, Mayberry, Alexander wrote:
>  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. 
Actually, I wanted to ensure you were planning to move to RHEL7 : The
version of 389-ds in RHEL7 should support the SSL features I discussed
that are key to your concerns.

>  
>  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. 
I'll let the RH engineers / consultants advise you on this, but I would
assume (and hope) the upgrade path they suggest is:

You have you existing Masters A and B.

You create new Masters C and D.

You put all 4 into replication group.

Apply the SSL settings discussed here to C and D.

Then you would put C and D into production alongside A and B.

Wait and test.

Then remove A and B from production for a period of time before you
decommision them.

>  
>  Thanks for your insight, and info, I appreciate it.
>   
Any time! 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane