Bug 1787115
| Summary: | [RFE] Need Method to copy SKI from CSR to Certificate signed. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Gaurav Swami <gswami> |
| Component: | pki-core | Assignee: | Jack Magne <jmagne> |
| Status: | CLOSED ERRATA | QA Contact: | PKI QE <bugzilla-pkiqe> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 | CC: | aakkiang, afarley, edewata, jmagne, mharmsen, msauton |
| Target Milestone: | rc | Keywords: | FutureFeature, TestCaseProvided |
| Target Release: | 8.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | pki-core-10.6-8040020201020223442.d4d99205 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-18 15:25:13 UTC | Type: | Feature Request |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
this is about cross CA certificates enrollment, it would be good to have a profile with the OID 2.5.29.14 - Subject Key Identifier as an example. should caCrossSignedCACert.cfg get updated or a new profile added? or just document in the admin guide? (there is an article that was published) M. is it the same feature as in the fixed/released bz RHEL-8.0 bz 1656856 - Need Method to Include SKI in CA Signing Certificate Request https://bugzilla.redhat.com/1656856 https://pagure.io/dogtagpki/issue/2854 and NSS update fixed in RHEL-7.7 with pki-core-10.5.16-3.el7 by errata https://access.redhat.com/errata/RHBA-2019:2228 and later in RHEL-8 by a pki-core rebase ? Checkin upstream:
Author: Jack Magne <jmagne>
Date: Thu Aug 6 09:48:18 2020 -0700
Address Bug 1787115 - [RFE] Need Method to copy SKI from CSR to Certificate signed.
This fix allows a way to configure a profile's SubjectKeyIdentifier process to optionally pick up
a SKI extension from the incoming CSR and use it instead of the one that is self calculated by the server.
Here is a proile snippet for the SKI as example:
policyset.caCertSet.8.default.name=Subject Key Identifier Extension Default
policyset.caCertSet.8.default.params.critical=false
policyset.caCertSet.8.default.params.messageDigest=SHA-1
policyset.caCertSet.8.default.params.useSKIFromCertRequest=true
Note the new param : useSKIFromCertRequest=true
This new param will default to false, thus not disturbing existing functionality.
When set to true, the CA will attempt to use the SKI extension within the CSR instead
of creating a new one unconditionally.
If the new param is fals or not present, the original functionality will execute.
If for some reason the ext can't be found in the CSR, the existing functionality will execute
as well.
Here is a simple CA Server CSR with a custom SKI to test with:
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC7zCCAdcCAQAwZTElMCMGA1UECgwcdG9wb2xvZ3ktMDNfRm9vYmFybWFzdGVyLm9yZzEbMBkG
A1UECxMSdG9wb2xvZ3ktMDMtQ0Etc2tpMR8wHQYDVQQDExZDQSBTaWduaW5nIENlcnRpZmljYXRl
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8Z1MUxsZ0AzV51ohgklOOF99O9pu3Akv
OqJA2p6B5eDxRMq3s8Dfhgg9Gh7Jtje067oYQrqQ8Y7fs1N3gI5O2F3275InKw1j6YfSwAZtq7K1
zl86ZHyI9CdHsZb1Xpb/vgyAb48mMSW2lF2Gy/4QpIQVHxpkxbxKaskEJHFE9BgptcMFaMxYGQDq
xYWpLluGyGeHYnmE9Fx3aMaj7oo5hAW7TaYRmi+LXrvuKf1EROJntm828wWYeIG+pFfvw3it80bq
j3xYo/6Vv2G1k1qqd4eKksbqZXMYkNKzNDkZkNgO/qRu0rL+S2KyAQmSejVmmZcjsHi/hqZoULE4
lG1kAQIDAQABoEUwQwYJKoZIhvcNAQkOMTYwNDARBgNVHQ4ECgQIANBvANTQZ0YwDwYDVR0TAQH/
BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwDQYJKoZIhvcNAQENBQADggEBAFPfkEGa0/m2MHOgZMUW
ZVh1hW4nmBRE9Q7ZNhG7xvZaOK7sUuavRhL4vQ1Qf7wjS0Br43LviOGyxL9S/E9ZUuAv4ckH7pfR
6iox/35mwF51MUm1+8RD7gCBeAQE97Bh/gBErmgWMMqlMVckf2jVwYuIbDy0DmSc41kLsMJlAmd7
rddGIxO8kFJm/CRnwomZTM9Y/FzIq1FK/Nz7nBBX7yWUd4TustAmiwmwofmZB+gf2B0kjI/p+2sH
uIBSWk6xdy57T3KKygtqgkDschyfTJAOHC67pCKPnPpslAOMEATxcgIV0PjP7XSvpivia1T/96Xq
cr8G9sE8VJ/hwno1l9k=
-----END NEW CERTIFICATE REQUEST-----
If the CSR doesn't have the extension while the param is set, the SKI will
be calculated as usual.
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 (Moderate: pki-core:10.6 and pki-deps:10.6 security, bug fix, and enhancement update), 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/RHSA-2021:1775 |
Description of problem: We need SKI from CSR to be copied into signed certificate by RHCS. As of now we have workaround If we have CSR with SKI extension and want to keep the SKI as-is, we must use a profile with the 'userExtensionDefaultImpl' component configured to copy the SKI extension to the final certificate as-is, e.g.: policyset.<name>.<idx>.constraint.class_id=noConstraintImpl policyset.<name>.<idx>.constraint.name=No Constraint policyset.<name>.<idx>.default.class_id=userExtensionDefaultImpl policyset.<name>.<idx>.default.name=User Supplied Extension Default policyset.<name>.<idx>.default.params.userExtOID=2.5.29.14 If the CSR does not have a SKI then we must use a profile that auto-generates the SKI extension, e.g.: policyset.<name>.<idx>.constraint.class_id=noConstraintImpl policyset.<name>.<idx>.constraint.name=No Constraint policyset.<name>.<idx>.default.class_id=subjectKeyIdentifierExtDefaultImpl policyset.<name>.<idx>.default.name=Subject Key Identifier Extension Def policyset.<name>.<idx>.default.params.critical=false What RHCS does not have is a single profile component that copies the SKI if it is present in CSR, otherwise creates the SKI extension automatically with a value derived from the key. Additional info: http://post-office.corp.redhat.com/archives/idm-tech/2019-December/msg00039.html