Case being a site has customized its cipher lists (sslRangeCiphers) in server.xml throughout all CS instances. new cipher list being a lot more stringent.
When installing new cs instance, the default ciphers does not overlap with the already-installed servers, including the Security Domain CA, hence making it not able to connect. Workaround is to loosen the ciphers on the SD CA and possibly others required during installation; however, that is not ideal, as it requires making changes and restarting the affected servers and changing them back later.
It would make better sense to allow admin to customize the cipher list of the to-be-installed instance before the actual installation.
We tried to enable the TLS_ECDHE cipher suite across the board for all components (sslRangeCiphers). The new cipher list just adds cipher suites to enable PFS, it doesn't remove them. However, with this new setting, additional RHCS components fail to install. If we wait until the environment is built, then flip on TLS_ECDHE, the CA is no longer able to communicate with the KRAs.
Per CS/DS Meeting of 10/12/2015 - 10.3 - Nice to Have
From IRC conversation of 10/20/2015: 10.3 - minor
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1303175
This can be done without adding new parameters: http://pki.fedoraproject.org/wiki/Custom_Installation#Customizing_TLS_cipher_list
Metadata Update from @cfu: - Issue assigned to edewata - Issue set to the milestone: 10.3.1
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/2203
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.