Red Hat Bugzilla – Bug 1305993
Add profile component that copies CN to SAN
Last modified: 2018-01-24 17:39:38 EST
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.
Per PKI Bug Council of 06/15/2016: 7.4
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
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 !!
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
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-----
Created attachment 1278116 [details] causercert profile
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.
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@me.com 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@me.com 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@me.com DNSName: 1.exampletest.com DNSName: pki1.example.com DNSName: mytest1.get.com Here first CN follows DNS format so it is considered and add.
Opened seperated bug Bug 1451188 - caUserCert profile couldn't parse multiple CN's while testing BZ 1305993. Marking this bug as verified.
Created attachment 1279212 [details] profile changes made for testing BZ
I tweaked the doc text: s/option/profile component/g.
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
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...
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.