If we have External CA certificate signed using nssdb or openssl, we can customize certificates where we can have a externalCA certificate which has no SKI and AKI extension added.
In my case, i wanted to try a use case where my RootCA when signed the certificate, the certificate which gets generated doesn't have a SKID of it's own and what i expected is since nssdb is RootCA and not dogtag is my RootCA which signs the certificate so it should not be adding any extensions while signing .I expected one of this outcome when i test this way:
Steps to Reproduce:
1.Create a RootCA using nssdb. <cmd> cmd = 'echo -e "y\n\ny\ny\n%s\n\n\n\n%s\n\n2\n7\n%s\n\n\n\n" | \ certutil -S \ -x \ -d /opt/pkitest/certdb \ -f password.txt \ -z noise.bin \ -n "RootCA" \ -s "CN=Root CA Signing Certificate,O=ROOT" \ -t "CT,C,C" \ -m $RANDOM\ -k rsa \ -g 2048 \ -Z SHA256 \ -2 \ -3 \ --extAIA \ --extSKID \ --keyUsage critical,certSigning,crlSigning,digitalSignature,nonRepudiation' %(rootca_skid, rootca_skid, ocsp) </cmd> Decrypt & see the RootCA certificate: ==================================== X509v3 extensions: Authority Information Access: OCSP - URI:http://pki1.example.com:8080/ca/ocsp X509v3 Subject Key Identifier: F7:38:A0:50:E0:FF:8E:10:78:C8:FD:7A:C7:5F:F0:A2:BA:39:70:72 X509v3 Authority Key Identifier: keyid:F7:38:A0:50:E0:FF:8E:10:78:C8:FD:7A:C7:5F:F0:A2:BA:39:70:72 2. Generate csr using CA step1 installation. Sign the certificate generated for the generated csr. <cmd> 'echo -e "0\n1\n5\n6\n9\ny\ny\n\ny\n" | \ certutil -C \ -d /opt/pkitest/certdb \ -f password.txt \ -m $RANDOM \ -a -i /tmp/test_dir/ca_signing.csr\ -o /tmp/test_dir/ca_signing.crt \ -c "RootCA" \ -1 -2' </cmd> Decrypt and check the certificate for ExternalCA: ================================================= Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical 3.Sign a certificate using this External CA and check the extensions.So External CA has no extensions but the certificate which External CA has an AKI extension. Extensions: *Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 9C:F6:EA:6A:9A:E1:10:C8:EA:8E:EE:D1:07:EA:AA:E1: DE:63:79:E6*
Actual results:
External CA installation works and certs that External CA signs picks random AKI.
Expected results:
If ExternalCA doesn't have a SKI/AKI, installation should fail.
Metadata Update from @mharmsen: - Custom field component adjusted to None - Custom field feature adjusted to None - Custom field origin adjusted to None - Custom field proposedmilestone adjusted to None - Custom field proposedpriority adjusted to None - Custom field reviewer adjusted to None - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1516118 - Custom field type adjusted to None - Custom field version adjusted to None - Issue priority set to: critical - Issue set to the milestone: 10.5
Per PKI Team Meeting of 20171130, moving to RHEL 10.6.
Metadata Update from @mharmsen: - Issue set to the milestone: 10.6 (was: 10.5)
This is duplicate of https://pagure.io/dogtagpki/issue/2309. Closing and setting milestone of #2309 to 10.6.
Metadata Update from @ftweedal: - Issue close_status updated to: duplicate
Metadata Update from @mharmsen: - Issue set to the milestone: 10.6.0 (was: 10.6)
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2984
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.