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.
Per CS/DS meeting of 10/19/2015: 10.3 - critical
From IRC conversation of 10/20/2015: 10.3 - critical
pushed to master: commit 562a49f08df2adb1a3f233a9b7490575182ece04
This patch allows the administrator to specify an allowed list of ssl ciphers for subsystem->subsystem communication that is separate from the server one in server.xml
Note:
How to test (what I have tested):
ca.connector.KRA.clientCiphers=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA - expect ca to connect to kra using the ciphers allowed in the clientCiphers list by doing an enrollment with archival - verify using ssltap or any tool that can catch and report from an ssl session
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1302136
Metadata Update from @cfu: - Issue assigned to cfu - Issue set to the milestone: 10.3.0
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2207
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.