Bug 1554055 - Permit certain SHA384 FIPS ciphers to be enabled by default for RSA and ECC . . .
Summary: Permit certain SHA384 FIPS ciphers to be enabled by default for RSA and ECC ....
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.6
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Christina Fu
QA Contact: Asha Akkiangady
Marc Muehlfeld
URL:
Whiteboard:
Depends On: 1550786
Blocks: 1554056 1554058 1632615
TreeView+ depends on / blocked
 
Reported: 2018-03-11 05:18 UTC by Matthew Harmsen
Modified: 2019-08-06 13:07 UTC (History)
8 users (show)

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.
Clone Of: 1550786
: 1554056 1632615 (view as bug list)
Environment:
Last Closed: 2019-08-06 13:07:17 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2228 None None None 2019-08-06 13:07:49 UTC

Comment 2 Matthew Harmsen 2018-03-11 05:23:31 UTC
It was determined that certain SHA384 FIPS ciphers should be enabled by default for RSA:

    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_RSA_WITH_AES_256_GCM_SHA384

and the following SHA384 FIPS ciphers should be enabled by default for ECC:

    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Reference:  Bug 1550786 - Permit additional FIPS ciphers to be enabled by default for RSA and ECC . . .

Comment 4 Matthew Harmsen 2018-05-04 22:51:08 UTC
Per RHEL 7.5.z/7.6/8.0 Triage:  7.5.z

Comment 7 Christina Fu 2018-08-28 16:42:12 UTC
will also address the following issue reported by Alexander Bokovoy (abokovoy@redhat.com) in this bug:
CA's CS.cfg contains the following:
ca.profiles.defaultSigningAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withEC,SHA512withEC
which is missing
SHA384withRSA

Comment 8 Christina Fu 2018-08-30 22:09:04 UTC
(In reply to Christina Fu from comment #7)
> will also address the following issue reported by Alexander Bokovoy
> (abokovoy@redhat.com) 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

Comment 9 Christina Fu 2018-08-31 16:20:25 UTC
Please ignore comments #7 and #8.

Up for review:
https://review.gerrithub.io/c/dogtagpki/pki/+/424251

Comment 10 Christina Fu 2018-08-31 18:50:56 UTC
commit fdda6408e6d5e7d350567902898a418a1136d5be (HEAD -> DOGTAG_10_5_BRANCH, origin/DOGTAG_10_5_BRANCH, ticket-2960-SHA384-ciphers-cleanProfilesD)
Author: Christina Fu <cfu@redhat.com>
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

Comment 11 Christina Fu 2018-08-31 19:18:37 UTC
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.

Comment 13 Christina Fu 2018-09-07 21:11:47 UTC
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@redhat.com>
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@users.noreply.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@redhat.com>

Comment 18 Sudhir Menon 2019-06-28 12:21:59 UTC
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.

Comment 20 errata-xmlrpc 2019-08-06 13:07:17 UTC
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


Note You need to log in before you can comment on or make changes to this bug.