Red Hat Bugzilla – Bug 1302136
[RFE] provide separate cipher lists for CS instances acting as client and server
Last modified: 2016-11-04 01:22:34 EDT
Currently the cipher list is specified in server.xml, and it is used when a CS instance is acting as server as well as client. However, the issue depicted in https://fedorahosted.org/pki/ticket/1576 subsystem -> subsystem SSL handshake issue with TLS_ECDHE_RSA_* on Thales HSM makes it so that CS->CS inter-subsystem communication has issues; We should not let it affect the servers open to other clients such as browsers and cli's. We should investigate on having the cipher lists separate for acting as server and client.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
https://fedorahosted.org/pki/ticket/1648#comment:4
[root@nocp4 ~]# rpm -qi pki-ca Name : pki-ca Version : 10.3.3 Release : 5.el7 Architecture: noarch Install Date: Fri 12 Aug 2016 01:14:29 PM EDT Group : System Environment/Daemons Size : 2430595 License : GPLv2 Signature : RSA/SHA256, Thu 11 Aug 2016 02:01:10 AM EDT, Key ID 938a80caf21541eb Source RPM : pki-core-10.3.3-5.el7.src.rpm Build Date : Tue 09 Aug 2016 07:47:56 AM EDT Build Host : ppc-021.build.eng.bos.redhat.com Relocations : (not relocatable) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : http://pki.fedoraproject.org/ Summary : Certificate System - Certificate Authority Verification steps: 1. Made config changes to CA and KRA's server.xml to add the ciphers as explained in https://fedorahosted.org/pki/ticket/1648#comment:4 2. Connecting to the agent pages of CA and KRA gave the following ssltap output (ssltap -sxl hostname:<secure-port>): handshake { 0: 02 00 00 53 | ...S type = 2 (server_hello) length = 83 (0x000053) ServerHello { server_version = {3, 3} random = {...} 0: 4b 30 d8 b6 e3 71 89 da 0f b5 89 06 99 c0 96 bd | K0...q.......... 10: 32 63 77 4b ff 45 b0 47 93 5a d1 1e 91 17 94 f6 | 2cwK.E.G.Z...... session ID = { length = 32 contents = {...} 0: 7f 4b 14 fa 95 28 c0 f0 de 20 ab fe 7e c7 1e 4f | K...(... ..~..O 10: 96 96 5f d7 3b 7b 7a 31 a9 42 7d 89 1b a4 3e 3c | .._.;{z1.B}...>< } cipher_suite = (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA compression method = (00) NULL extensions[11] = { extension type renegotiation_info, length [1] = { 0: 00 | . } extension type ec_point_formats, length [2] = { 0: 01 00 | .. } } } 3. For testing key archival I did tps token enrollment using tpsclient. I noticed that following cipher being used with all the connectors tps-ca, tps-kra and tps-tks handshake { 0: 02 00 00 4d | ...M type = 2 (server_hello) length = 77 (0x00004d) ServerHello { server_version = {3, 3} random = {...} 0: 23 6b 9a 6f 02 73 1b 69 45 0b d1 1e 3b 6a 17 7b | #k.o.s.iE...;j.{ 10: e4 3b 2a ec b4 cf 11 0d 3f e6 71 96 a8 54 3d a2 | .;*.....?.q..T=. session ID = { length = 32 contents = {...} 0: 6c c7 a1 4a 15 d0 62 16 00 7b 19 b9 28 c0 c7 f3 | l..J..b..{..(... 10: 13 80 d9 f2 78 05 88 f5 d3 53 3b db 2c b1 c4 c1 | ....x....S;.,... } cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA compression method = (00) NULL extensions[5] = { extension type renegotiation_info, length [1] = { 0: 00 | . } } I did not make any changes to the cipherlist in CS.cfg to test this (as explained in ticket 1648). The parameter ca.connector.KRA.clientCiphers= did not exist in CS.cfg (not in TPS CS.cfg either).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2396.html