#2864 ExternalCA certificate validation during installation
Closed: duplicate Opened by mharmsen.

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:

  1. Once it could not find any extension either it should throw some
    exception like skid is missing .signing of certs using this CA will fail
    etc.
    -- agree
  2. While generating subsystem certs it will fail because the ExternalCA
    is signer for them and it doesn't have SKID.So the certificate doesn't
    have an AKI.( It should reach to this point, if AKI check is mandatory
    to have)
    -- I agree in general. But a simpler solution is to just check the ca signing cert upfront (installation and startup)

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.

Thank you for understanding, and we apologize for any inconvenience.

Metadata