Bug 1305993

Summary: Add profile component that copies CN to SAN
Product: Red Hat Enterprise Linux 7 Reporter: Matthew Harmsen <mharmsen>
Component: pki-coreAssignee: Fraser Tweedale <ftweedal>
Status: CLOSED ERRATA QA Contact: Asha Akkiangady <aakkiang>
Severity: unspecified Docs Contact: Petr Bokoc <pbokoc>
Priority: high    
Version: 7.3CC: arubin, ftweedal, gkapoor, nkinder, pbokoc, pioto
Target Milestone: rcKeywords: ZStream
Target Release: 7.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pki-core-10.4.0-1.el7 Doc Type: Enhancement
Doc Text:
Added a profile component to copy certificate Subject Common Name to the Subject Alternative Name extension 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` profile component, 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:
: 1429492 (view as bug list) Environment:
Last Closed: 2017-08-01 22:46:01 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:    
Bug Blocks: 1429492    
Attachments:
Description Flags
causercert profile
none
profile changes made for testing BZ none

Description Matthew Harmsen 2016-02-09 18:32:30 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/pki/ticket/1710

Add a profile component that copies the CN to SAN dnsName (if it
looks like a domain name), which can be used to issue certificates
compliant with RFC 2818.

Care must be taken to ensure that the component works with other
components that add the SAN extension.

See https://fedorahosted.org/freeipa/ticket/4970 for more info.
Comment 1 Matthew Harmsen 2016-06-15 18:46:34 UTC 
Per PKI Bug Council of 06/15/2016:  7.4
Comment 4 Matthew Harmsen 2017-03-03 18:31:34 UTC 
ftweedal:

Pushed to master:

    31dfbb569756e8c28500b597ac4486f780761c4c Add upgrade script to add CommonNameToSANDefault plugin
    9cb00049ec731cca36de822f6c1e834f7febcb4f Add profile component that copies CN to SAN dNSName
    979b6a2da433e97c1ada6434b432aa4aabc47ab5 X500Name: add method to get all attributes of a given type
    a67816eebbed2332327fbf391f3e23223ee7690e SubjectAlternativeNameExtension: add GeneralNames getter/setter
    225dd099efa7e2f752c3f50157aaec71a9834873 GeneralName: add method to get at inner value
    f371114134ee3b6a83b747eecf46e001080b1e9c DNSName: add method to get value
Comment 7 Geetika Kapoor 2017-05-11 12:15:27 UTC 
Hi Fraser,

I am testing this Bugzilla.So based on my understanding :

1. If we have a CN which looks like a domain,"Identifier: Subject Alternative Name " should be populated in certificate.

Example : I have used profile caUserCert with below details.

Subject: UID=test,CN=example.com

So I could see SAN getting added which is as expected.

Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        DNSName: example.com

Test Case 1:
=============
 Now i change the subject to Subject: UID=test,CN=*.m.example.com

So now i don't see a SAN extension. "*.m.example.com" is a valid domain.
Do we support wild card?

Test Case 2:
============

Do we support multiple SAN's in one cert request. ex: Multihoming with multiple addresses could be an example.

Test Case 3:
=============

I have read a line in RFC (https://tools.ietf.org/html/rfc5280#page-35) :

Because the subject alternative name is considered to be definitively
   bound to the public key, all parts of the subject alternative name
   MUST be verified by the CA.

This means like if we specify a domain CA should be verifying it? Not sure what it exactly meant for.


Thanks !!
Comment 8 Fraser Tweedale 2017-05-12 04:08:35 UTC 
Hi Geetika,

1. No, we don't accept wildcard.  Wildcard DNS identifiers in certificates
are deprecated (RFC 6125); furthermore although widely accepted it is
technically not a valid SAN according to RFC 5280.  So we are not going to
accept them here.

2. Yes.  But we only copy (at most) one CN from the Subject DN to SAN.
If there are multiple CNs in the subject DN, only the "most specific"
is examined (this is the leftmost value in NSS presentation, and rightmost
in OpenSSL presentation).

But we do support any number of SANs.  If a CN gets copied to SAN, it gets
"merged" info the existing lits of SANs.

3. This is out of scope.  Validation and authorisation is performed by the
agent-operator or by other profile components.

Thanks,
Fraser
Comment 9 Geetika Kapoor 2017-05-12 09:49:24 UTC 
Hi Fraser,

So here we go .Here are all the details and all the testing results which doesn't look as expected when we have multiple CN's in subject which can be a common scenario in case of Multihoming with multiple addresses.

I have used profile caUserCert.I am attaching that file too.

Test Case 1: Testing with single CN's in subject. 
===========


example:

Subject: UID=test,CN=pki1.example.com

Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        DNSName: pki1.example.com

Test Case 2: Testing with multiple CN's in subject.
============

Csr:
====

-----BEGIN CERTIFICATE REQUEST-----
MIIBjDCB9gIBADBNMRYwFAYDVQQDEw0xLmV4YW1wbGUuY29tMRkwFwYDVQQDExB0
ZXN0LmV4YW1wbGUuY29tMRgwFgYKCZImiZPyLGQBARMIdGVzdHVzZXIwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALQE7BbrvZdvldHRpMrymFP7tAKgL8ljH5dt
7tg3JxUWyfBgHim8UXdgsmDPE8T3u012zi/hzCc6csOrVki4xnlTkc8V8orIIneR
X4DCSP5PlEL/1LoCDMby/dUMvsX0fUd4hHwYguVfwfZqpWXW+F50cLLirk8WMsBd
c2EzdGqhAgMBAAGgADANBgkqhkiG9w0BAQsFAAOBgQBxHcxexX+zAQCzPytiw/uW
rsp0J17YY2v2tvNRDtI9uPL9AU+WVHHATL7T5sB2mACyGkwAQ5+KoaJMJX2m0esI
5pmtVafLcGIuNeZi445pgvQW/EWhHteB6gFlP3yVDWuRmgTzV7nA3C0zB1rv3DG8
7kPqvBfcWRbSRn0zGScMJg==

-----END CERTIFICATE REQUEST-----

cert:
======

 Certificate   0x02a
 
Certificate contents

    Certificate: 
        Data: 
            Version:  v3
            Serial Number: 0x2A
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
            Validity: 
                Not Before: Friday, May 12, 2017 2:53:58 PM IST Asia/Kolkata
                Not  After: Wednesday, November 8, 2017 2:53:58 PM IST Asia/Kolkata
            Subject: UID=testuser\,CN\=test.example.com\,CN\=1.example.com
            Subject Public Key Info: 
                Algorithm: RSA - 1.2.840.113549.1.1.1
                Public Key: 
                    Exponent: 65537
                    Public Key Modulus: (1024 bits) :
                        B4:04:EC:16:EB:BD:97:6F:95:D1:D1:A4:CA:F2:98:53:
                        FB:B4:02:A0:2F:C9:63:1F:97:6D:EE:D8:37:27:15:16:
                        C9:F0:60:1E:29:BC:51:77:60:B2:60:CF:13:C4:F7:BB:
                        4D:76:CE:2F:E1:CC:27:3A:72:C3:AB:56:48:B8:C6:79:
                        53:91:CF:15:F2:8A:C8:22:77:91:5F:80:C2:48:FE:4F:
                        94:42:FF:D4:BA:02:0C:C6:F2:FD:D5:0C:BE:C5:F4:7D:
                        47:78:84:7C:18:82:E5:5F:C1:F6:6A:A5:65:D6:F8:5E:
                        74:70:B2:E2:AE:4F:16:32:C0:5D:73:61:33:74:6A:A1
            Extensions: 
                Identifier: Authority Key Identifier - 2.5.29.35
                    Critical: no 
                    Key Identifier: 
                        23:C1:52:30:49:97:F1:33:3E:6E:97:96:1D:86:59:1F:
                        3F:E6:E2:A4
                Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1
                    Critical: no 
                    Access Description: 
                        Method #0: ocsp
                        Location #0: URIName: http://pki1.example.com:20080/ca/ocsp
                Identifier: Key Usage: - 2.5.29.15
                    Critical: yes 
                    Key Usage: 
                        Digital Signature 
                        Non Repudiation 
                        Key Encipherment 
                Identifier: Extended Key Usage: - 2.5.29.37
                    Critical: no 
                    Extended Key Usage: 
                        1.3.6.1.5.5.7.3.2
                        1.3.6.1.5.5.7.3.4
        Signature: 
            Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Signature: 
                B2:EB:E9:A2:5D:63:AF:D1:9A:B5:82:BB:71:08:B1:38:
                27:BD:BF:AA:85:3A:5C:86:C3:2A:DB:B3:0E:2E:40:99:
                3E:68:92:A6:C3:A0:0B:AB:EB:91:81:38:FB:D9:66:9F:
                76:00:E9:27:A9:67:0F:A2:9B:C2:89:5F:EC:83:20:C0:
                BC:D6:B0:FA:F1:05:D5:CF:54:AF:3D:8E:E3:57:13:1B:
                69:CE:6C:0C:B3:99:B4:80:3D:84:91:66:0C:4C:1C:B1:
                DA:F1:0B:64:38:19:CE:64:A8:12:B3:4B:16:7B:E2:91:
                3A:90:C4:B2:69:69:D0:A1:3A:52:9C:26:61:A1:9E:28:
                8E:86:73:73:77:E7:4A:B0:9E:BB:61:E7:C6:C6:7C:73:
                C2:47:F9:D5:E9:ED:04:4D:5D:66:55:EF:89:A1:CF:48:
                64:13:21:E4:A5:7C:A6:5A:94:4B:2D:DB:56:AC:59:EE:
                3C:D5:9C:F4:52:D5:B8:67:98:6D:32:A7:49:3C:C9:A5:
                E1:0F:DB:36:AF:67:F9:BE:15:68:96:7A:71:CB:80:5A:
                92:6B:9F:6F:8F:AF:71:19:3D:CD:37:D8:9A:E4:71:74:
                49:D9:54:C3:5A:ED:FA:D2:AC:5B:7E:DA:DA:05:58:CA:
                0D:F1:64:0F:8F:D2:81:4F:0C:8F:E9:94:44:F2:51:B1
        FingerPrint
            MD2:
                D0:22:CA:4B:00:CF:B3:74:86:A3:F0:73:15:4C:62:29
            MD5:
                5D:F7:3E:49:5A:26:EA:45:8E:75:47:49:90:54:95:D1
            SHA-1:
                87:0D:7C:05:9E:AD:E3:42:B4:0D:75:98:FE:C0:C0:4D:
                E3:20:62:6D
            SHA-256:
                19:0A:9F:68:4A:8B:C4:FA:59:E8:95:DE:31:85:4F:8F:
                C0:80:04:A1:9B:1F:26:EC:BB:4E:E5:65:82:3C:1E:39
            SHA-512:
                00:EF:8D:8B:1D:7A:E6:EF:28:A9:5F:14:D5:73:BB:BB:
                B8:75:58:A2:C6:CC:23:F6:D9:E1:96:5F:AE:E3:9E:45:
                68:FD:3B:6C:4E:A3:BD:5A:DC:19:FD:58:65:80:1C:8E:
                09:90:FC:4F:75:9D:8D:C6:C6:44:76:44:B7:2E:95:C7

Certificate request info

Request ID: 48

Installing this certificate in a server

The following format can be used to install this certificate into a server.

Base 64 encoded certificate

-----BEGIN CERTIFICATE-----
MIIDLjCCAhagAwIBAgIBKjANBgkqhkiG9w0BAQsFADBhMSUwIwYDVQQKDBx0b3Bv
bG9neS0wMl9Gb29iYXJtYXN0ZXIub3JnMRcwFQYDVQQLDA50b3BvbG9neS0wMi1D
QTEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTAeFw0xNzA1MTIwOTIz
NThaFw0xNzExMDgwOTIzNThaMD8xPTA7BgoJkiaJk/IsZAEBDC10ZXN0dXNlcixD
Tj10ZXN0LmV4YW1wbGUuY29tLENOPTEuZXhhbXBsZS5jb20wgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBALQE7BbrvZdvldHRpMrymFP7tAKgL8ljH5dt7tg3JxUW
yfBgHim8UXdgsmDPE8T3u012zi/hzCc6csOrVki4xnlTkc8V8orIIneRX4DCSP5P
lEL/1LoCDMby/dUMvsX0fUd4hHwYguVfwfZqpWXW+F50cLLirk8WMsBdc2EzdGqh
AgMBAAGjgZYwgZMwHwYDVR0jBBgwFoAUI8FSMEmX8TM+bpeWHYZZHz/m4qQwQQYI
KwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vcGtpMS5leGFtcGxlLmNv
bToyMDA4MC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBALLr6aJdY6/RmrWCu3EI
sTgnvb+qhTpchsMq27MOLkCZPmiSpsOgC6vrkYE4+9lmn3YA6SepZw+im8KJX+yD
IMC81rD68QXVz1SvPY7jVxMbac5sDLOZtIA9hJFmDEwcsdrxC2Q4Gc5kqBKzSxZ7
4pE6kMSyaWnQoTpSnCZhoZ4ojoZzc3fnSrCeu2HnxsZ8c8JH+dXp7QRNXWZV74mh
z0hkEyHkpXymWpRLLdtWrFnuPNWc9FLVuGeYbTKnSTzJpeEP2zavZ/m+FWiWenHL
gFqSa59vj69xGT3NN9ia5HF0SdlUw1rt+tKsW37a2gVYyg3xZA+P0oFPDI/plETy
UbE=
-----END CERTIFICATE-----

Base 64 encoded certificate with CA certificate chain in pkcs7 format

-----BEGIN PKCS7-----
MIIHSgYJKoZIhvcNAQcCoIIHOzCCBzcCAQExADAPBgkqhkiG9w0BBwGgAgQAoIIH
GzCCAy4wggIWoAMCAQICASowDQYJKoZIhvcNAQELBQAwYTElMCMGA1UECgwcdG9w
b2xvZ3ktMDJfRm9vYmFybWFzdGVyLm9yZzEXMBUGA1UECwwOdG9wb2xvZ3ktMDIt
Q0ExHzAdBgNVBAMMFkNBIFNpZ25pbmcgQ2VydGlmaWNhdGUwHhcNMTcwNTEyMDky
MzU4WhcNMTcxMTA4MDkyMzU4WjA/MT0wOwYKCZImiZPyLGQBAQwtdGVzdHVzZXIs
Q049dGVzdC5leGFtcGxlLmNvbSxDTj0xLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQC0BOwW672Xb5XR0aTK8phT+7QCoC/JYx+Xbe7YNycV
FsnwYB4pvFF3YLJgzxPE97tNds4v4cwnOnLDq1ZIuMZ5U5HPFfKKyCJ3kV+Awkj+
T5RC/9S6AgzG8v3VDL7F9H1HeIR8GILlX8H2aqVl1vhedHCy4q5PFjLAXXNhM3Rq
oQIDAQABo4GWMIGTMB8GA1UdIwQYMBaAFCPBUjBJl/EzPm6Xlh2GWR8/5uKkMEEG
CCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL3BraTEuZXhhbXBsZS5j
b206MjAwODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCy6+miXWOv0Zq1grtx
CLE4J72/qoU6XIbDKtuzDi5AmT5okqbDoAur65GBOPvZZp92AOknqWcPopvCiV/s
gyDAvNaw+vEF1c9Urz2O41cTG2nObAyzmbSAPYSRZgxMHLHa8QtkOBnOZKgSs0sW
e+KROpDEsmlp0KE6UpwmYaGeKI6Gc3N350qwnrth58bGfHPCR/nV6e0ETV1mVe+J
oc9IZBMh5KV8plqUSy3bVqxZ7jzVnPRS1bhnmG0yp0k8yaXhD9s2r2f5vhVolnpx
y4Bakmufb4+vcRk9zTfYmuRxdEnZVMNa7frSrFt+2toFWMoN8WQPj9KBTwyP6ZRE
8lGxMIID5TCCAs2gAwIBAgIBATANBgkqhkiG9w0BAQsFADBhMSUwIwYDVQQKDBx0
b3BvbG9neS0wMl9Gb29iYXJtYXN0ZXIub3JnMRcwFQYDVQQLDA50b3BvbG9neS0w
Mi1DQTEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTAeFw0xNzA1MTEw
NjU3MzhaFw0zNzA1MTEwNjU3MzhaMGExJTAjBgNVBAoMHHRvcG9sb2d5LTAyX0Zv
b2Jhcm1hc3Rlci5vcmcxFzAVBgNVBAsMDnRvcG9sb2d5LTAyLUNBMR8wHQYDVQQD
DBZDQSBTaWduaW5nIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEA3E+/aqRLh+23xL0tP7l7Mo4M/9JQ1w7CYBOPNH09Se1lgjSeh13C
XNM293fdOEoYe4jFZSERvD1ftOi3sGfYoC70+YlPcbscqUgM8nha1gK9OM70Iezs
XwzPtZdoZIxvK64bllqzKfNcFdKUAx/2awghfov18NVgGxXNX9Yts4YlM6WPLDgn
W+wEzco6Yf3Qar5zigz9GFLjW2gL0nzfeMvQN5xWIqEWxjY7Zu+Q0RJaokat1t7J
Ad1sE/Q1ByiGdsFcVJSfCcy4QQyRL6Uqjtl6oZUMnvdA095A5lCW2AsCQrNL7AnX
4j0OvfouPIg9o5DyKVubdSDoPEb7Noa2YwIDAQABo4GnMIGkMB8GA1UdIwQYMBaA
FCPBUjBJl/EzPm6Xlh2GWR8/5uKkMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/
BAQDAgHGMB0GA1UdDgQWBBQjwVIwSZfxMz5ul5YdhlkfP+bipDBBBggrBgEFBQcB
AQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9wa2kxLmV4YW1wbGUuY29tOjIwMDgw
L2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAKYlpqNGxl/nXly2OPJ+oJIcotZN
yUVbKBXfxgoJCqQZXV7XUcbBRCo4kfg/jcv2EH20K60kgC7jdTr9RKCp4KS/A7Lj
LYXce6aGxR0x+Zyt2wsxzAVJ4dJr/9S3yM57IlJeMGPop20nZOGpXqYceeGkJqG3
gonbZyTDsb5lO4QMqhttAnfMOlXnhlPPEdpqQluMYr5UQ6ynbvXXSvPMYOec3GzK
yLluhgxZtuO2DL/iiStrD5jd15nyxhsUObTYIF/uCVk1ae1qVAH0ULvyhppjCP7y
DuZmiEwZAe4GuRx+Er/oGf/pn8ob+5aDkjnVuLJ613YNfLD715QrFqGJoQIxAA==
-----END PKCS7-----
Comment 10 Geetika Kapoor 2017-05-12 09:50:40 UTC 
Created attachment 1278116 [details]
causercert profile
Comment 11 Geetika Kapoor 2017-05-12 10:55:24 UTC 
With CaServerCert:
====================

SAN is picked as expected and the "most specific" CN, and is the one that should be included in the SAN.Here in nss it is the first one from left.

Certificate: 
        Data: 
            Version:  v3
            Serial Number: 0x30
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
            Validity: 
                Not Before: Friday, May 12, 2017 3:59:33 PM IST Asia/Kolkata
                Not  After: Thursday, May 2, 2019 3:59:33 PM IST Asia/Kolkata
            Subject: CN=test.example.com,CN=1.example.com
            Subject Public Key Info: 
                Algorithm: RSA - 1.2.840.113549.1.1.1
                Public Key: 
                    Exponent: 65537
                    Public Key Modulus: (1024 bits) :
                        F6:09:F3:EE:D0:C9:7E:EE:71:7D:FE:D5:8D:D4:F9:35:
                        F5:73:2C:9D:4F:7C:1D:7C:77:DD:02:76:C8:E8:5A:6E:
                        D1:02:9C:D5:6E:8C:B5:A4:42:99:F1:FE:87:1A:D5:75:
                        23:A2:13:41:41:33:A3:A9:AE:F5:19:AC:08:1B:E2:0B:
                        03:1D:65:ED:E1:CE:A0:F8:97:68:F8:E1:43:7E:08:C3:
                        0C:05:09:B1:80:4D:21:EF:94:21:8A:4F:48:D8:A5:77:
                        2D:52:1E:11:8D:6C:EE:59:6C:C5:07:EB:30:44:C8:52:
                        D8:20:37:9E:34:76:44:AE:9C:18:7E:C9:28:C3:D3:0F
            Extensions: 
                Identifier: Authority Key Identifier - 2.5.29.35
                    Critical: no 
                    Key Identifier: 
                        23:C1:52:30:49:97:F1:33:3E:6E:97:96:1D:86:59:1F:
                        3F:E6:E2:A4
                Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        DNSName: test.example.com

So for CaUserCert, multiple CN are not taken properly.CSR construction is not as expected.I'll file a separate bug for the same.
Comment 12 Geetika Kapoor 2017-05-15 19:18:10 UTC 
Test Cases for caServerCert:
-----------------------------

1. Generate PKcs10 request using :

PKCS10Client -d nssdb/ -p Secret123 -a rsa -l 1024 -o testuserno.csr -n "C=IT,OU=redhat.com,CN=mytest.get.com,CN=pki1.example.com,CN=test.example.com,CN=1.exampletest.com"

2. Send this csr to CA Agent.
3. certificate should look like using config:
============================================================================

[root@pki1 ~]# grep "policyset.serverCertSet.12." /var/lib/pki/topology-02-CA/ca/profiles/ca/caServerCert.cfgpolicyset.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.subjAltExtGNEnable_1=true
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_2=true
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.serverCertSet.12.default.params.subjAltExtPattern_1=$request.req_subject_name.cn$
policyset.serverCertSet.12.default.params.subjAltExtPattern_2=pki1.example.com
policyset.serverCertSet.12.default.params.subjAltExtType_0=RFC822Name
policyset.serverCertSet.12.default.params.subjAltExtType_1=DNSName
policyset.serverCertSet.12.default.params.subjAltExtType_2=DNSName
policyset.serverCertSet.12.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=5
[root@pki1 ~]# grep "policyset.serverCertSet.11." /var/lib/pki/topology-02-CA/ca/profiles/ca/caServerCert.cfg
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
====================================================================

cert:
Subject: C=IT,OU=redhat.com,CN=mytest.get.com,CN=pki1.example.com,CN=test.example.com,CN=1.exampletest.com


     Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                    RFC822Name: test
                    DNSName: 1.exampletest.com ==>$request.req_subject_name.cn$
                        DNSName: pki1.example.com ==> .subjAltExtPattern_2
                        DNSName: mytest.get.com ==> left hand side most specific based on nss.

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

Test case 2:  
Subject: C=IT,OU=redhat.com,CN=humptydumpty,OU=fixit,CN=mytest1.get.com,CN=pki1.example.com,CN=test.example.com,CN=1.exampletest.com

  Value: 
                        RFC822Name: test
                        DNSName: 1.exampletest.com
                        DNSName: pki1.example.com

Since the first CN doesn't look like a DNS so it is skipped.
===========================================================================

Test Case 3:

Subject: C=IT,OU=redhat.com,OU=humptydumpty,OU=fixit,CN=mytest1.get.com,CN=pki1.example.com,CN=test.example.com,CN=1.exampletest.com

output:

                Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no 
                    Value: 
                        RFC822Name: test
                        DNSName: 1.exampletest.com
                        DNSName: pki1.example.com
                        DNSName: mytest1.get.com

Here first CN follows DNS format so it is considered and add.
Comment 13 Geetika Kapoor 2017-05-16 05:42:37 UTC 
Opened seperated bug 
Bug 1451188 - caUserCert profile couldn't parse multiple CN's while testing BZ 1305993.
Marking this bug as verified.
Comment 14 Geetika Kapoor 2017-05-16 05:45:35 UTC 
Created attachment 1279212 [details]
profile changes made for testing BZ
Comment 15 Fraser Tweedale 2017-07-25 23:48:20 UTC 
I tweaked the doc text: s/option/profile component/g.
Comment 16 errata-xmlrpc 2017-08-01 22:46:01 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-2017:2110
Comment 17 Mike Kelly 2018-01-19 19:28:46 UTC 
Is there any way to add this to the existing caIPAserviceCert profile in an existing IPA environment?

It looks like it's present by default in a fresh install, but doesn't seem to have been added during an upgrade from previous releases...
Comment 18 Fraser Tweedale 2018-01-24 22:39:38 UTC 
Mike, if the entire IPA topology has pki-core-10.4.0-1.el7 or greater,
then you can use the `ipa certprofile-show caIPAserviceCert --out caIPAserviceCert.cfg` to write the existing profile configuration to file,
update it to add the new profile component, then use `ipa certprofile-mod`
to update the profile with the new configuration.

We don't yet have a profile update framework that can handle mixed-version
topologies; this is why, by default, the component is only used in new
installations.