Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1429492

Summary: Add profile component that copies CN to SAN
Product: Red Hat Enterprise Linux 7 Reporter: Jaroslav Reznik <jreznik>
Component: pki-coreAssignee: RHCS Maintainers <rhcs-maint>
Status: CLOSED ERRATA QA Contact: Asha Akkiangady <aakkiang>
Severity: unspecified Docs Contact:
Priority: high    
Version: 7.3CC: arubin, cfu, ftweedal, gkapoor, mharmsen, ndehadra, nkinder, pbokoc
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pki-core-10.3.3-18.el7_3 Doc Type: Enhancement
Doc Text:
* Some TLS libraries now warn or refuse to validate DNS names when the DNS name only appears in the Subject Common Name (CN) field, which is a practice that was deprecated by RFC 2818. This update adds the "CommonNameToSANDefault", which copies the Subject Common Name to the Subject Alternative Name (SAN) extension, and ensures that certificates are compliant with current standards.
 Story Points: ---
Clone Of: 1305993 Environment:
Last Closed: 2017-04-12 12:37:20 UTC Type: ---
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: 1305993    
Bug Blocks:    

Description Jaroslav Reznik 2017-03-06 13:42:34 UTC 
This bug has been copied from bug #1305993 and has been proposed
to be backported to 7.3 z-stream (EUS).
Comment 5 Matthew Harmsen 2017-03-07 03:21:38 UTC 
The following check-ins were cherry-picked to DOGTAG_10_3_RHEL_BRANCH:

commit 10799f1af01143ffb27fae06f446bb389c0787e8
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:39:14 2017 +1000

    Add profile component that copies CN to SAN dNSName
    
    Add the 'CommonNameToSANDefault' profile default class.  When used
    on a profile, this will examine the (most-specific) Common Name in
    the Subject DN, and if it looks like a DNS name, will add it to the
    Subject Alternative Name extension, creating the extension if it
    does not already exist.
    
    Also add upgrade scriptlet to add the component to registry.cfg in
    existing installations.
    
    Fixes: https://fedorahosted.org/pki/ticket/1710
    (cherry picked from commit 9cb00049ec731cca36de822f6c1e834f7febcb4f)
    (cherry picked from commit 10d1db00225caf750ccc3c50b9d6e6b7af3655a8)

commit da8cab2d15d5bd5e82ad8bd9a2ff0f51f7bad343
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:30:50 2017 +1000

    X500Name: add method to get all attributes of a given type
    
    To implement a profile default that copies the CN to a SAN dNSName,
    we need to examine the CN values present in the Subject DN.
    Specifically, we want to look at the "most specific" CN value.  The
    'getCommonName' method returns the "least specific" value in the
    name, thus is not suitable.
    
    Add the 'getAttributesForOid(ObjectIdentifier)' method, which
    returns an ordered list of values of the given name attribute type,
    from least specific to most specific.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit 979b6a2da433e97c1ada6434b432aa4aabc47ab5)
    (cherry picked from commit 4ba23db518ab285d8a0dce8d4ee493f695867ad8)

commit 6eac5bbccb18fe913c43a0b9ec73707180870bb9
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:25:11 2017 +1000

    SubjectAlternativeNameExtension: add GeneralNames getter/setter
    
    To implement a profile default that copies CN to SAN dNSName, we
    need to read and set the 'GeneralNames' of the extension.  This can
    be done via the 'get' and 'set' methods but this interface is
    awkward and requires the caller to deal with exceptions that aren't
    fundamental to the get/set actions.
    
    Add the 'setGeneralNames' and 'getGeneralNames' methods.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit a67816eebbed2332327fbf391f3e23223ee7690e)
    (cherry picked from commit 60f4011c3f4511ac8f86b77940d25b5869204353)

commit 6fa86d4f50b5846f5d6f8a12797f61dd5b629cca
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:17:51 2017 +1000

    GeneralName: add method to get at inner value
    
    The 'GeneralNameInterface' interface represents a single X.509
    General Name value.  Various types are supported.  The 'GeneralName'
    class (which also implements 'GeneralNameInterface') is a singleton
    container for another 'GeneralNameInterface' value.
    
    To implement a profile component that copies CN to a SAN dNSName, we
    need to examine existing General Names in the SAN extension (if
    present), to avoid duplicate values.  We can iterate 'GeneralNames',
    but if the value is of type 'GeneralName' we need a way to "unwrap"
    the value, down to the innermost value which will be of a specific
    General Name type.
    
    Add the 'unwrap' method to 'GeneralName'.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit 225dd099efa7e2f752c3f50157aaec71a9834873)
    (cherry picked from commit 52704d6564800c6872d3343c9aa5d6180637f070)

commit fa65ec19458bbd767f54e52f61d920b529936e19
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:15:39 2017 +1000

    DNSName: add method to get value
    
    To implement a profile default that copies CN to SAN dNSName, we
    need to examine existing dNSName values.  To support this, add the
    'getValue()' method to 'DNSName'.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit f371114134ee3b6a83b747eecf46e001080b1e9c)
    (cherry picked from commit a30f25cbb496b6e24b417a02602e0cdbe079cbd3)
Comment 6 Matthew Harmsen 2017-03-07 03:23:12 UTC 
The following check-ins were cherry-picked to DOGTAG_10_3_RHEL_UNRELEASED_BRANCH:

commit 2aa7eaee9ff74e52e38421641970d6aa1cc66f21
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:39:14 2017 +1000

    Add profile component that copies CN to SAN dNSName
    
    Add the 'CommonNameToSANDefault' profile default class.  When used
    on a profile, this will examine the (most-specific) Common Name in
    the Subject DN, and if it looks like a DNS name, will add it to the
    Subject Alternative Name extension, creating the extension if it
    does not already exist.
    
    Also add upgrade scriptlet to add the component to registry.cfg in
    existing installations.
    
    Fixes: https://fedorahosted.org/pki/ticket/1710
    (cherry picked from commit 9cb00049ec731cca36de822f6c1e834f7febcb4f)
    (cherry picked from commit 10d1db00225caf750ccc3c50b9d6e6b7af3655a8)

commit 1a0c12dfa5a6b77eadd717345c0d343bafb77b28
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:30:50 2017 +1000

    X500Name: add method to get all attributes of a given type
    
    To implement a profile default that copies the CN to a SAN dNSName,
    we need to examine the CN values present in the Subject DN.
    Specifically, we want to look at the "most specific" CN value.  The
    'getCommonName' method returns the "least specific" value in the
    name, thus is not suitable.
    
    Add the 'getAttributesForOid(ObjectIdentifier)' method, which
    returns an ordered list of values of the given name attribute type,
    from least specific to most specific.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit 979b6a2da433e97c1ada6434b432aa4aabc47ab5)
    (cherry picked from commit 4ba23db518ab285d8a0dce8d4ee493f695867ad8)

commit df932ae599b1f86d4fbc6d5cef3bb387dc09cf68
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:25:11 2017 +1000

    SubjectAlternativeNameExtension: add GeneralNames getter/setter
    
    To implement a profile default that copies CN to SAN dNSName, we
    need to read and set the 'GeneralNames' of the extension.  This can
    be done via the 'get' and 'set' methods but this interface is
    awkward and requires the caller to deal with exceptions that aren't
    fundamental to the get/set actions.
    
    Add the 'setGeneralNames' and 'getGeneralNames' methods.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit a67816eebbed2332327fbf391f3e23223ee7690e)
    (cherry picked from commit 60f4011c3f4511ac8f86b77940d25b5869204353)

commit 1d8c68e1062c24c764b4498cf3a68c6be11832c7
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:17:51 2017 +1000

    GeneralName: add method to get at inner value
    
    The 'GeneralNameInterface' interface represents a single X.509
    General Name value.  Various types are supported.  The 'GeneralName'
    class (which also implements 'GeneralNameInterface') is a singleton
    container for another 'GeneralNameInterface' value.
    
    To implement a profile component that copies CN to a SAN dNSName, we
    need to examine existing General Names in the SAN extension (if
    present), to avoid duplicate values.  We can iterate 'GeneralNames',
    but if the value is of type 'GeneralName' we need a way to "unwrap"
    the value, down to the innermost value which will be of a specific
    General Name type.
    
    Add the 'unwrap' method to 'GeneralName'.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit 225dd099efa7e2f752c3f50157aaec71a9834873)
    (cherry picked from commit 52704d6564800c6872d3343c9aa5d6180637f070)

commit 55b8495a43e91992253015641f29fb0bd47ba8b9
Author: Fraser Tweedale <ftweedal>
Date:   Wed Feb 1 16:15:39 2017 +1000

    DNSName: add method to get value
    
    To implement a profile default that copies CN to SAN dNSName, we
    need to examine existing dNSName values.  To support this, add the
    'getValue()' method to 'DNSName'.
    
    Part of: https://fedorahosted.org/pki/ticket/1710
    
    (cherry picked from commit f371114134ee3b6a83b747eecf46e001080b1e9c)
    (cherry picked from commit a30f25cbb496b6e24b417a02602e0cdbe079cbd3)
Comment 9 Fraser Tweedale 2017-03-15 11:03:52 UTC 
Steps to verify:

Install CS.  The new profile component should be available in the default
configuration.

Then you have to configure a profile to actually use the new                                                           
component.  I would recommend to modify `caServerCert' or whatever
profile you usually use for testing basic certificate issuance.
The required configuration will be something like:                                                                  
                                                                                                                       
    policyset.serverCertSet.<N>.default.class_id=commonNameToSANDefaultImpl                                             
    policyset.serverCertSet.<N>.default.name=Copy Common Name to Subject Alternative Name                               
    policyset.serverCertSet.<N>.constraint.class_id=noConstraintImpl                                                    
    policyset.serverCertSet.<N>.constraint.name=No Constraint                                                           
                                                                                 
- Substitute `<N>' with the next unused number in the profile configuration.
- Add N to the END of the `policyset.serverCertSet.list' parameter
- Update the profile configuration

Finally test certificate issuance.  The complete test matrix is:

1. There is a single CN in CSR, and it does not look like DNS name
    1.1 SAN extension already present -> no changes
    1.2 No SAN extension present -> no SAN extension gets created

2. There is a single CN in CSR and it looks like a DNS name:
    2.1. SAN extension already present:
        2.1.1. SAN already has a DNSName equal (case insensitive) to CN -> no changes to SAN (i.e. a duplicate should not be added)
        2.1.2. Otherwise -> add CN as a dNSName to existing SAN extension
    2.2. SAN extension not already present -> add SAN extension with CN as a dNSName

3. There are multiple CNs that look like DNS name in CSR:
    3.1. The "most-specific" CN is copied to SAN, creating it if necessary
Comment 10 Geetika Kapoor 2017-03-17 10:01:29 UTC 
Build details: pki-ca-10.3.3-18.el7_3.noarch
--------------

Test Steps:
-----------

1. Pick a profile.I have used "caUserCert". Location :/var/lib/pki/topology-02-CA/ca/profiles/ca/caUserCert.cf
2. Disable the profile before editing it using:

pki -p 20080 -d /tmp/ff -c Secret123 -n "PKI CA Administrator for Example.Org" ca-profile-disable caUserCert

3. Make changes in profile using 

pki -p 20080 -d /tmp/ff -c Secret123 -n "PKI CA Administrator for Example.Org" ca-profile-edit caUserCert

Added below parameters:

policyset.userCertSet.11.default.class_id=commonNameToSANDefaultImpl
policyset.userCertSet.11.default.constraint.class_id=noConstraintImpl
policyset.userCertSet.11.default.constraint.name=No Constraint
policyset.userCertSet.11.default.default.name=Copy Common Name to Subject Alternative Name


4. Now try to add 11 in the list using cli as well as manually.
Add "11" to the END of the `policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9` parameter.So first i tried to disable and then edit the same in caUserCert.cfg but got below exception. 

 pki -p 20080 -d /tmp/ff -c Secret123 -n "PKI CA Administrator for Example.Org" ca-profile-disable caUserCert
-----------------------------
Disabled profile "caUserCert"
-----------------------------
 pki -p 20080 -d /tmp/ff -c Secret123 -n "PKI CA Administrator for Example.Org" ca-profile-edit caUserCert
BadRequestException: Invalid profile data


5. Tried adding manually.No exception throw but the same profile property is not getting reflected on CA Agent page.
Ideally this property needs to be visible under CA Agent page --> Manager Certificate profile --> caUserCert .Right now i see only 10 Fields/Extensions listed.

Can you please have a look if something else needs to be done here.
Comment 11 Fraser Tweedale 2017-03-20 02:50:31 UTC 
The configuration is not correct.  It should be:                                                                             
                                                                                                                       
policyset.<name>.<n>.default.class_id=commonNameToSANDefaultImpl                                                       
policyset.<name>.<n>.default.name=Copy Common Name to Subject Alternative Name                                         
policyset.<name>.<n>.constraint.class_id=noConstraintImpl                                                              
policyset.<name>.<n>.constraint.name=No Constraint                                                                     
                                                                                                                       
I'd also suggest modifying a profile designed for server/service                                                       
certs, e.g. caServerCert, because a user cert typically does not have                                                    
a hostname as the CN and therefore the component won't do anything.                                                    
                                                                                                                       
If the profile is set up correctly, you will see the component                                                         
listed in the profile's "Manage Certificate Profiles" page, in the                                                     
agent web-ui.
Comment 12 Asha Akkiangady 2017-03-21 05:06:20 UTC 
Tested with following configuration for the caUserCert profile, certificate request with subject DN containing CN=myhost1.test.example.com results in a certificate with DNSName: myhost1.test.example.com in SAN.

policyset.userCertSet.11.constraint.class_id=noConstraintImpl
policyset.userCertSet.11.constraint.name=No Constraint
policyset.userCertSet.11.default.class_id=commonNameToSANDefaultImpl
policyset.userCertSet.11.default.name=Copy Common Name to Subject Alternative Name

policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9,11


caServerCert profile with following configuration also successfully added the subjectDN CN=pki1.example.com to SAN creating extension DNSName: pki1.example.com

policyset.serverCertSet.11.constraint.class_id=noConstraintImpl
policyset.serverCertSet.11.constraint.name=No Constraint
policyset.serverCertSet.11.default.class_id=commonNameToSANDefaultImpl
policyset.serverCertSet.11.default.name=Copy Common Name to Subject Alternative Name

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,11
Comment 13 Asha Akkiangady 2017-03-22 02:54:57 UTC 
Tested following scenarios:
#1. SAN extension not already present, CN looks like DNS name, CN as DNSName should be added in SAN extension.
- caServerCert profile is configured as in comment #12
- Subject DN has CN=pki1.example.com

- Result: Certificate is generated with the following Subject DN and SAN extension:
Subject: CN=pki1.example.com
...
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        DNSName: pki1.example.com

=====================================================
#2. SAN extension not already present, CN doesn't look like DNS name, CN as a DNSName shouldn't be added in SAN extension.
- caServerCert profile is configured as in comment #12
- Subject DN has CN=test

- Result:
Subject: CN=test

CN as a DNSName is not added as SAN extension

=====================================================
#3. SAN extension already present and SAN already has a DNSName equal, CN looks like DNS name, it should not add CN as a DNSName to existing SAN extension.
- Configure caUserCert profile to have DNSName as SAN extension.
policyset.userCertSet.8.constraint.class_id=noConstraintImpl
policyset.userCertSet.8.constraint.name=No Constraint
policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.userCertSet.8.default.name=Subject Alt Name Constraint
policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
policyset.userCertSet.8.default.params.subjAltExtGNEnable_1=true
policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.userCertSet.8.default.params.subjAltExtPattern_1=pki1.example.com
policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.userCertSet.8.default.params.subjAltExtType_1=DNSName
policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
policyset.userCertSet.8.default.params.subjAltNameNumGNs=2

- caUserCert profile is configured to copy CN to SAN as in comment #12

- Result:  Certificate is generated with the following Subject DN and SAN extension:
Subject: UID=testuser2,E=testuser2,CN=pki1.example.com
....
 Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser2
                        DNSName: pki1.example.com
===========
Test using caServerCert profile:
- Configure caServerCert profile to have DNSName as SAN extension.
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alt Name Constraint
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=pki1.example.com
policyset.serverCertSet.12.default.params.subjAltExtType_0=DNSName
policyset.serverCertSet.12.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=1

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,12,11

- caServerCert profile is configured to copy CN to SAN as in comment #12

- Result:  Certificate is generated with the following Subject DN and SAN extension:
Subject: CN=pki1.example.com
....
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        DNSName: pki1.example.com

==============================================================
#4. SAN extension already present and SAN already has a DNSName equal, CN looks like DNS name and is different from the one configured in the profile.
Should add CN as a DNSName to existing SAN extension (?).
- Configure caUserCert profile to have DNSName as SAN extension.
policyset.userCertSet.8.constraint.class_id=noConstraintImpl
policyset.userCertSet.8.constraint.name=No Constraint
policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.userCertSet.8.default.name=Subject Alt Name Constraint
policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
policyset.userCertSet.8.default.params.subjAltExtGNEnable_1=true
policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.userCertSet.8.default.params.subjAltExtPattern_1=pki1.example.com
policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.userCertSet.8.default.params.subjAltExtType_1=DNSName
policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
policyset.userCertSet.8.default.params.subjAltNameNumGNs=2

- caUserCert profile is configured to copy CN to SAN as in comment #12

- Result:  Certificate is generated with the following Subject DN and SAN extension:
Subject: UID=testuser2,E=testuser2,CN=dummyname.testdom.com
....
               Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser2
                        DNSName: pki1.example.com
                        DNSName: dummyname.testdom.com

============
Test using caServerCert profile:
- Configure caServerCert profile to have DNSName as SAN extension.
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alt Name Constraint
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=pki1.example.com
policyset.serverCertSet.12.default.params.subjAltExtType_0=DNSName
policyset.serverCertSet.12.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=1

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,12,11

- caServerCert profile is configured to copy CN to SAN as in comment #12

- Result:  Certificate is generated with the following Subject DN and SAN extension:
 Subject: CN=dummy.host.example.com
....
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        DNSName: pki1.example.com
                        DNSName: dummy.host.example.com
================================================================
#5. SAN extension already present and SAN doesn't have DNSName equal, CN looks like DNS name, it should add CN as a DNSName to existing SAN extension.
- caUserCert profile has SAN extension like this:
policyset.userCertSet.8.constraint.class_id=noConstraintImpl
policyset.userCertSet.8.constraint.name=No Constraint
policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.userCertSet.8.default.name=Subject Alt Name Constraint
policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
policyset.userCertSet.8.default.params.subjAltNameNumGNs=1

- caUserCert profile is configured to copy CN to SAN as in comment #12


Certificate is generated with the following Subject DN and SAN extension:
Subject: UID=testuser2,E=testuser2,CN=pki1.example.com
.....
                Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser2
                        DNSName: pki1.example.com
=========
Test using caServerCert profile:
- caServerCert profile has SAN extension like this:
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alt Name Constraint
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=testuser1
policyset.serverCertSet.12.default.params.subjAltExtType_0=RFC822Name
policyset.serverCertSet.12.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=1

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,12,11
- caServerCert profile is configured to copy CN to SAN as in comment #12

- Result:  Certificate is generated with the following Subject DN and SAN extension:
Subject: CN=pki1.example.com
....
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser1
                        DNSName: pki1.example.com
=================================================================
#6. SAN extension already present and SAN doesn't have DNSName equal, CN doesn't looks like DNS name, it shouldn't add CN as a DNSName to existing SAN extension.
- caUserCert profile has SAN extension like this:
policyset.userCertSet.8.constraint.class_id=noConstraintImpl
policyset.userCertSet.8.constraint.name=No Constraint
policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.userCertSet.8.default.name=Subject Alt Name Constraint
policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
policyset.userCertSet.8.default.params.subjAltNameNumGNs=1

- caUserCert profile is configured to copy CN to SAN as in comment #12


Certificate is generated with the following Subject DN and SAN extension:
Subject: UID=testuser2,E=testuser2,CN=testuser2
...
  Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser2
=============
Test using caServerCert profile:
- caServerCert profile has SAN extension like this:
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alt Name Constraint
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=testuser1
policyset.serverCertSet.12.default.params.subjAltExtType_0=RFC822Name
policyset.serverCertSet.12.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=1

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,12,11
- caServerCert profile is configured to copy CN to SAN as in comment #12

- Result:  Certificate is generated with the following Subject DN and SAN extension:
Subject: CN=pkihost1
...
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser1
===============================================
#7. 
a. SAN doesn't already exist, subject DN has multiple CNs, it should add most specific CN as a DNSName to SAN extension.

- caServerCert profile is configured as in comment #12
- Subject DN has multiple CN parameters.

Certificate is generated with the following Subject DN and SAN extension:
Subject: CN=test,CN=pki1.example.com,CN=testing,CN=dummy.test
....
Result: No SAN extension added.


b. SAN extension already present and SAN doesn't have DNSName equal, subject DN has multiple CNs, it should add most specific CN as a DNSName to SAN extension.

- caServerCert profile has SAN extension like this:
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alt Name Constraint
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=testuser1
policyset.serverCertSet.12.default.params.subjAltExtType_0=RFC822Name
policyset.serverCertSet.12.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=1

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,12,11
- caServerCert profile is configured to copy CN to SAN as in comment #12

- Result: Certificate is generated with the following Subject DN and SAN extension:
Subject: CN=test,CN=pki1.example.com,CN=testing,CN=dummy.test
...
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser1

There is no SAN extension with DNSName. 

c. Same set-up as 7.b.
"Subject: CN=dummy.test,CN=pki1.example.com,CN=testing" cert generated with following extension:
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: testuser1
                        DNSName: dummy.test


==================================================


Hi Fraser, 
I have following questions:

1. In #4 are the expected and the actual results correct?

2. In #7 I did not get the expected result. Could you please explain what's the most specific CN in this scenario? It should have picked CN=pki1.example.com and added it as DNSName extension to SAN?

Thanks,
Asha
Comment 14 Fraser Tweedale 2017-03-22 03:49:39 UTC 
Asha, thanks for your comprehensive testing.

#4 is all good.

#7 is also correct.  "Most specific" refers to the order of attributes in
   the subject DN.  i.e. in "CN=dummy.test,CN=pki1.example.com,CN=testing",
   the "most specific" CN is "dummy.test".  So the result is correct;
   the most specific in 7a and 7b is "CN=test" which does not meet the
   criteria of "looks like a domain name" and therefore does not get added,
   whereas in 7c "CN=dummy.test" does meet the criteria, and gets added.

  (FYI, tools based on NSS use "ldap order" were "most specific" is the
  leftmost attribute, whereas OpenSSL formats DNs in "X.500 order" with
  most specific on the right.
Comment 15 Asha Akkiangady 2017-03-22 20:35:41 UTC 
Thanks Fraser.

Scenario #3 is also tested with "$request.req_subject_name.cn$":

policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alt Name Constraint
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=$request.req_subject_name.cn$
policyset.serverCertSet.12.default.params.subjAltExtType_0=DNSName
policyset.serverCertSet.12.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=1

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,12,11

- Result: Certificate is generated with the following Subject DN and SAN extension:
Subject: CN=pki1.example.com
...
Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        DNSName: pki1.example.com

SAN extension with CN as a dNSName is not added to existing SAN extension as expected.

Marking the bug verified.
Comment 17 errata-xmlrpc 2017-04-12 12:37:20 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/RHEA-2017:0922
Comment 18 Christina Fu 2017-10-19 21:19:34 UTC 
Fraser, is this documented anywhere?  Could you make sure it is tracked to go into 9.3 guidance doc?
Here is where we dump our latest design/usage info for techpub:
https://pki.fedoraproject.org/wiki/PKI_Design

thanks
Comment 19 Fraser Tweedale 2017-10-20 04:23:16 UTC 
Closest thing we have documentation for this is a blog post:
https://blog-ftweedal.rhcloud.com/2017/07/implications-of-common-name-deprecation-for-dogtag-and-freeipa/#configuring-commonnametosandefault

I'll leave the needinfo for now to remind me to copy that info to that
wiki page.
Comment 20 Fraser Tweedale 2017-11-20 05:21:05 UTC 
OK, I finally wrote up the feature design page:
https://pki.fedoraproject.org/wiki/PKI_10.4_Copy_CN_To_SAN.