Bug 1554055
Summary: | Permit certain SHA384 FIPS ciphers to be enabled by default for RSA and ECC . . . | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Matthew Harmsen <mharmsen> | |
Component: | pki-core | Assignee: | Christina Fu <cfu> | |
Status: | CLOSED ERRATA | QA Contact: | Asha Akkiangady <aakkiang> | |
Severity: | urgent | Docs Contact: | Marc Muehlfeld <mmuehlfe> | |
Priority: | urgent | |||
Version: | 7.6 | CC: | aakkiang, cfu, cpelland, lmiksik, mjahoda, msauton, sumenon, toneata | |
Target Milestone: | rc | Keywords: | TestCaseProvided, ZStream | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | pki-core-10.5.16-2.el7 | Doc Type: | Enhancement | |
Doc Text: |
.Certificate System now supports additional strong ciphers by default
With this update, the following additional ciphers, which are compliant with the Federal Information Processing Standard (FIPS), are enabled by default in Certificate System:
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_RSA_WITH_AES_256_GCM_SHA384
For a full list of enabled ciphers, enter:
# /usr/lib64/nss/unsupported-tools/listsuites | grep -B1 --no-group-separator "Enabled"
If you use a Hardware Security Module (HSM) with Certificate System, see the documentation of the HSM for supported ciphers.
|
Story Points: | --- | |
Clone Of: | 1550786 | |||
: | 1554056 1632615 (view as bug list) | Environment: | ||
Last Closed: | 2019-08-06 13:07:17 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 1550786 | |||
Bug Blocks: | 1554056, 1554058, 1632615 |
Comment 2
Matthew Harmsen
2018-03-11 05:23:31 UTC
Per RHEL 7.5.z/7.6/8.0 Triage: 7.5.z will also address the following issue reported by Alexander Bokovoy (abokovoy) in this bug: CA's CS.cfg contains the following: ca.profiles.defaultSigningAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withEC,SHA512withEC which is missing SHA384withRSA (In reply to Christina Fu from comment #7) > will also address the following issue reported by Alexander Bokovoy > (abokovoy) in this bug: > CA's CS.cfg contains the following: > ca.profiles.defaultSigningAlgsAllowed=SHA256withRSA,SHA512withRSA, > SHA256withEC,SHA384withEC,SHA512withEC > which is missing > SHA384withRSA moved to: https://bugzilla.redhat.com/show_bug.cgi?id=1578389#c5 Please ignore comments #7 and #8. Up for review: https://review.gerrithub.io/c/dogtagpki/pki/+/424251 commit fdda6408e6d5e7d350567902898a418a1136d5be (HEAD -> DOGTAG_10_5_BRANCH, origin/DOGTAG_10_5_BRANCH, ticket-2960-SHA384-ciphers-cleanProfilesD) Author: Christina Fu <cfu> Date: Fri Aug 31 08:52:22 2018 -0700 Ticket2960 add SHA384 ciphers and cleanup profiles This patch adds SHA384 ciphers to the default cipher lists (RSA & EC). Also added SHA384withRSA to ca.profiles.defaultSigningAlgsAllowed. In addition, a few cleanups are done: - all MD2, MD5 from allowed signing key algs from profiles - server profiles: * removed clientAuth oid 1.3.6.1.5.5.7.3.2 from a couple server profiles * fixed a couple KU's (RSA vs EC) that had true/false flipped - caCMCkraStorageCert.cfg * removed EKU (funny it had clientAuth) - caCMCkraTransportCert.cfg * removed EKU (funny it had clientAuth) - base/ca/shared/conf/eccServerCert.profile * added the missing CommonNameToSANDefault Tested with the following: - installation of an RSA CA and a KRA (strip down to only SHA384 ciphers) * performed successful agent access * tested key archival - installation of an EC CA (strip down to only SHA384 ciphers) * performed successful agent access * tested an agent-signed CMC request and submitted/issued successfully using HttpClient The above tests showed: - The SHA384 ciphers work out of box - The TLS server and client profiles changes did not break any TLS connections. - The KRA storage and transport profile changes did not break anything. fixes https://pagure.io/dogtagpki/issue/2960 Change-Id: I6f5cc90ba0eb4a5bfb85d86abbe2c28882cbc6ca Test procedures: Tests can be conducted as specified under "Tested with the following:" in comment #10. In addition, you can tests some of the profiles by enrolling and using them per their functions. commit 97e290663f29d5b2c5afab18e4a7c90af05c874c (HEAD -> DOGTAG_10_5_BRANCH, origin/DOGTAG_10_5_BRANCH, ladycfu/ticket-2960-SHA384-ciphers-cleanProfilesD2, ticket-2960-SHA384-ciphers-cleanProfilesD2) Author: Christina Fu <cfu> Date: Fri Aug 31 08:52:22 2018 -0700 Ticket2960 add SHA384 ciphers and cleanup profiles Note: this is a 2nd attempt as the first attempt was reverted due to "breakage" of post-checkin-enablement of the IPA CI, which is speculated to have used a server cert as a client cert which violated one of the very essence of the "profile cleanup" part of the original patch; As a compromise, the clientAuth bit was added back to all non-CMC *server* profiles so the patch will pass the IPA CI. The revised patch has been adquately tested in addition to passing the IPA CI. This patch adds SHA384 ciphers to the cipher lists (RSA & EC) CryptoUtil.java contains changes to clientECCiphers: - RSA ciphers comemented out - SHA384 ciphers are added but RSA ones commented out Also added SHA384withRSA to ca.profiles.defaultSigningAlgsAllowed. In addition, a few cleanups are done: - all MD2, MD5 from allowed signing key algs from profiles - server profiles: * removed clientAuth oid 1.3.6.1.5.5.7.3.2 from cmc server profiles * fixed a couple KU's (RSA vs EC) that had true/false flipped - caCMCkraStorageCert.cfg * removed EKU (funny it had clientAuth) - caCMCkraTransportCert.cfg * removed EKU (funny it had clientAuth) - base/ca/shared/conf/eccServerCert.profile * added the missing CommonNameToSANDefault Tested with the following: - installation of an RSA CA and a KRA (strip down to only SHA384 ciphers) * performed successful agent access * tested key archival - installation of an EC CA (strip down to only SHA384 ciphers) * performed successful agent access * tested an agent-signed CMC request and submitted/issued successfully using HttpClient The above tests showed: - The SHA384 ciphers work out of box - The TLS server and client profiles changes did not break any TLS connections. - The KRA storage and transport profile changes did not break anything. fixes https://pagure.io/dogtagpki/issue/2960 Change-Id: Ia41dfbcec972cb18752b50056f29edf61cb3ce61 commit 62130fcb55ffaeaea65677742b10162d44909484 Author: Dinesh Prasanth M K <SilleBille.github.com> Date: Thu Sep 6 21:07:27 2018 -0400 Enabling IPA test with cleaner CI scripts & revert 2 commits (#42) - Reverting "Ticket 2960 and 3027" commits: fdda6408e6d5e7d350567902898a418a1136d5be 04ddc823762b5400f22409bbaceac1a8344708ca - Custom docker images are removed (https://pagure.io/dogtagpki/issue/3058) - ipa-docker-test-runner tool is removed (https://pagure.io/dogtagpki/issue/3059) - Cleaned up CI scripts Signed-off-by: Dinesh Prasanth M K <dmoluguw> Tested on RHEL 7.7 using FIPS enabled system [root@csqa4-guest03 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.7 Beta (Maipo) [root@csqa4-guest03 ~]# sysctl crypto.fips_enabled crypto.fips_enabled = 1 [root@csqa4-guest03 ~]# rpm -q pki-ca 389-ds-base pki-ca-10.5.16-3.el7.noarch 389-ds-base-1.3.9.1-10.el7.x86_64 Observations: 1. MD2withRSA/MD5withRSA allowed signing key algs are removed from all profiles. 2. MD2withRSA/MD5withRSA was present in caTransportCert.cfg profile. Hence logged a seperate #bz1724433 to track this issue. [root@pki1 ~]# grep MD5 /var/lib/pki/topology-01-CA/ca/profiles/ca/*.cfg /var/lib/pki/topology-01-CA/ca/profiles/ca/caTransportCert.cfg:policyset.transportCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withRSA,SHA384withEC,SHA512withEC 3. For caCMCkraStorageCert.cfg Extended Key Usage has been removed policyset.drmStorageCertSet.list=1,2,3,4,5,6,9 (Removed 7 from the list) Removed the below parameters policyset.drmStorageCertSet.7.constraint.class_id=noConstraintImpl policyset.drmStorageCertSet.7.constraint.name=No Constraint policyset.drmStorageCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl policyset.drmStorageCertSet.7.default.name=Extended Key Usage Extension Default policyset.drmStorageCertSet.7.default.params.exKeyUsageCritical=false policyset.drmStorageCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.2 4. For caCMCkraTransportCert EKU has been removed. policyset.transportCertSet.list=1,2,3,4,5,6,8 (removed 7 from the list) Removed the below parameters policyset.transportCertSet.7.constraint.class_id=noConstraintImpl policyset.transportCertSet.7.constraint.name=No Constraint policyset.transportCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl policyset.transportCertSet.7.default.name=Extended Key Usage Extension Default policyset.transportCertSet.7.default.params.exKeyUsageCritical=false policyset.transportCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.2 5. For eccServerCert.profile in /usr/share/pki/ca/conf/eccServerCert.profile CommonNameToSANDefault is present. [root@pki1 conf]# grep SAN /usr/share/pki/ca/conf/eccServerCert.profile 8.default.class=com.netscape.cms.profile.def.CommonNameToSANDefault 8.default.name=copy CN to SAN Default 6. clientAuth oid 1.3.6.1.5.5.7.3.2 is not present in CMC profiles. 7. Installation of CA and KRA with SHA384withRSA is successful without any errors. 8. Installation of EC CA with SHA384withEC is successful without any errors. 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://access.redhat.com/errata/RHBA-2019:2228 |