Post the existing Root CA certificate and the new DogTag SubCA certificate (in Base64-encoded format) to the forum. Without looking at the certificates, its hard to debug the issue.

Also, do you have the current Root CA's certificate stored as a trusted CA within DogTag's cert-store, and within the web-server with which you are trying to establish an SSL connection?

Arshad Noor StrongAuth, Inc. Michael StJohns wrote: > Hi - > > One of my customers has an existing root key pair and CA cert that > exists outside of Dogtag. I want to create a CA immediately > subordinate to that root CA and use Dogtag for it. > > After numerous attempts to adopt Dogtag to an external CA, I admit to > defeat. I've tried this with and without a PKCS7 chain, I've tried > various extensions and formats for the new CA cert, etc. > > The CA system comes up, looks good, but looking at the SSL hand shake > with "openssl s_client" shows that the server isn't providing the > entire chain, only the certificate for the server itself. > > Taking all of the certs in the chain from root through server and > running them through the Java cert path checking routines seems to > indicate the certs are fine. > > > If I build a system from scratch - with a new root cert and key pair > in one CA and then build a subordinate CA under that in the same > domain it works perfectly. > > Has anyone else tried this? If so, can you give me a step-by-step > please? > > Help! > > Mike > > _______________________________________________ > Pki-users mailing list > Pki-users(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-users

I believe your problem may be due to the fact that your self-signed Root CA certificate does not contain the AuthorityKeyIdentifier (AKI) extension - it only has the SubjectKeyIdentifier (SKI) extension.

While many tools may be forgiving of the fact that both extensions are not in the self-signed Root CA's certificate (and continue based on the Subject DN matching the Issuer DN), this is not a very secure means of establishing trust in a certificate chain.

The secure and PKIX-compliant way of validating a certificate-chain is (amongst many other tests) to match the SKI and AKI values of the Root certificate to determine if it is truly a self-signed certificate. I'm not sure if DogTag performs this level of validation, but I think it does (someone from RedHat will, hopefully, confirm this). You might want to consider renewing your existing Root CA certificate and ensuring that the AKI is also present when generating the renewal cert. Then insert this new Root CA cert into your cert-store and see if the chain is completed successfully. It might do the trick. Arshad Noor StrongAuth, Inc. P.S. Your cert-chain does not appear to be valid; openssl does not seem to recognize the content in there; the size of the Base64-text looks too small to contain two certificates in it.

Michael StJohns wrote: > On 4/4/2010 5:58 PM, Arshad Noor wrote: >> Post the existing Root CA certificate and the new DogTag SubCA >> certificate (in Base64-encoded format) to the forum. Without >> looking at the certificates, its hard to debug the issue. > --- The root cert as a PEM Base64 > > -----BEGIN CERTIFICATE----- > MIIDMjCCAhygAwIBAgIBATALBgkqhkiG9w0BAQswNjELMAkGA1UEBhMCVVMxGDAW > BgNVBAoMD050aCBQZXJtdXRhdGlvbjENMAsGA1UEAwwEUm9vdDAeFw0xMDAyMTYy > MjA1MDhaFw0yMDAyMTYyMjA1MDhaMDYxCzAJBgNVBAYTAlVTMRgwFgYDVQQKDA9O > dGggUGVybXV0YXRpb24xDTALBgNVBAMMBFJvb3QwggEiMA0GCSqGSIb3DQEBAQUA > A4IBDwAwggEKAoIBAQCXuCMKNdsl4t0bKoW0Uome9IesO/oJheUS/Fm6KNhW7NpD > WHuXznA+MmUm83OqpIeJYdZk55zLqdf2AEnbmIZF0+TowlbxNwR0z/rybGxmjULP > L/aARHUWFaG0megg6OyDwyQPGokWxqFFcBKZw6q3ifkPRgYzXJ8wrBnRn0wV0874 > b1cx+wXLNIxxWwif84vub49CcxBNBtrA6zTJ2W4arHdWiqvgyffFxEz/yQQ4xD4M > 3vYqXA/yWI/DOORnSfNtXDgtWLJBYyV7nutLeYZ9JUExBr2ojnScj6gxjl84OZiX > gIE8rlRyn2PsppFCgOImMK7JwhL/roS39Yq7qpyXAgMBAAGjTzBNMBEGA1UdIAQK > MAgwBgYEVR0gADALBgNVHQ8EBAMCAQYwDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQU > yO80tNZuETcbWYJEb6t5yaJrPs8wCwYJKoZIhvcNAQELA4IBAQAnUx0Jl0dvYI8T > ezHSS+KjjzMJ44Bc/aqx5MB4IngI7ZSO/ssBkzhGkTleO4rcx1zXN2BorheqxC/U > RS1p7KBahsXoR0exhaFKLO5g+W3WI8kiklCKtZLA8+g9f2OhlG6m4q6kHU/osxtW > 2fCeoOSy5ecXpiXuwtM6DD+7z/WkjPzJ79rXO526CF7oPWEoky/CvlyjV9v2kmw7 > ihUGvVBAbhwJ2SWohUDik+pwO7zXxtYQhovHW6uMvnLuA5tVqJrCNYb0CGSc9ejx > Rtn+sd/zIFSsO4T+Dam5lBNZnlCm2JkyB22OvHf326eQ+XB2qC9tsXMfrGE7kEO8 > UyTSUW+7 > -----END CERTIFICATE----- > > -- the root cert as a PKCS7 formatted chain > -----BEGIN CERTIFICATE CHAIN----- > MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqhkiG9w0BBwGggAQBAAAAAACg > ggM2MIIDMjCCAhygAwIBAgIBATALBgkqhkiG9w0BAQswNjELMAkGA1UEBhMC > VVMxGDAWBgNVBAoMD050aCBQZXJtdXRhdGlvbjENMAsGA1UEAwwEUm9vdDAe > Fw0xMDAyMTYyMjA1MDhaFw0yMDAyMTYyMjA1MDhaMDYxCzAJBgNVBAYTAlVT > MRgwFgYDVQQKDA9OdGggUGVybXV0YXRpb24xDTALBgNVBAMMBFJvb3QwggEi > MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXuCMKNdsl4t0bKoW0Uome > 9IesO/oJheUS/Fm6KNhW7NpDWHuXznA+MmUm83OqpIeJYdZk55zLqdf2AEnb > mIZF0+TowlbxNwR0z/rybGxmjULPL/aARHUWFaG0megg6OyDwyQPGokWxqFF > cBKZw6q3ifkPRgYzXJ8wrBnRn0wV0874b1cx+wXLNIxxWwif84vub49CcxBN > BtrA6zTJ2W4arHdWiqvgyffFxEz/yQQ4xD4M3vYqXA/yWI/DOORnSfNtXDgt > WLJBYyV7nutLeYZ9JUExBr2ojnScj6gxjl84OZiXgIE8rlRyn2PsppFCgOIm > MK7JwhL/roS39Yq7qpyXAgMBAAGjTzBNMBEGA1UdIAQKMAgwBgYEVR0gADAL > BgNVHQ8EBAMCAQYwDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUyO80tNZuETcb > WYJEb6t5yaJrPs8wCwYJKoZIhvcNAQELA4IBAQAnUx0Jl0dvYI8TezHSS+Kj > jzMJ44Bc/aqx5MB4IngI7ZSO/ssBkzhGkTleO4rcx1zXN2BorheqxC/URS1p > 7KBahsXoR0exhaFKLO5g+W3WI8kiklCKtZLA8+g9f2OhlG6m4q6kHU/osxtW > 2fCeoOSy5ecXpiXuwtM6DD+7z/WkjPzJ79rXO526CF7oPWEoky/CvlyjV9v2 > kmw7ihUGvVBAbhwJ2SWohUDik+pwO7zXxtYQhovHW6uMvnLuA5tVqJrCNYb0 > CGSc9ejxRtn+sd/zIFSsO4T+Dam5lBNZnlCm2JkyB22OvHf326eQ+XB2qC9t > sXMfrGE7kEO8UyTSUW+7MQAAAAAAAAA= > -----END CERTIFICATE CHAIN----- > > ---- the CA certificate signed by the above > -----BEGIN CERTIFICATE----- > MIIDXjCCAkigAwIBAgIBNzALBgkqhkiG9w0BAQswNjELMAkGA1UEBhMCVVMxGDAW > BgNVBAoMD050aCBQZXJtdXRhdGlvbjENMAsGA1UEAwwEUm9vdDAeFw0xMDA0MDQy > MTQ0MTVaFw0xNTA0MDQyMTQ0MTVaME4xCzAJBgNVBAYTAlVTMRgwFgYDVQQKDA9O > dGggUGVybXV0YXRpb24xJTAjBgNVBAMMHE50aCBQZXJtdXRhdGlvbiBDb3Jwb3Jh > dGUgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc8z1FxRTKvGmX > hY/KTQKECT4SqqWO+Jj/rWFS/JfPJ9XftUnth19C3cOAL2X+DzdaHKgXO9Mr3LJ+ > Y9xEPD2ItKk0dft+sE5LJHyXqKAZZfgsgZy3ez5/XA4UicHzFyyam6usoE71+QW6 > H17B0r3zDxC1EL/bfYs1R3pd8gLmlgxjnWNuRRWiCuvPtkjzJqgU2W5Dga+PQKWX > IHy5HfKwWldcwMBraLtc8srHM7qADI+lx/FOHXA4n+LETr3gxQ4StWVuKMbjmjhT > K9xLBW/2MfN3ZgXaIbDb6WYHdk0NYoYxaQ68L4I5a9aOt02FXnbAhxv4sDobtNbl > ruSDsWKhAgMBAAGjYzBhMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEA > MB0GA1UdDgQWBBQOA4DNZ2XFXK/sp3fxwYrZ9EdfVzAfBgNVHSMEGDAWgBTI7zS0 > 1m4RNxtZgkRvq3nJoms+zzALBgkqhkiG9w0BAQsDggEBADLQHjx2N+63QDiWDrm0 > fe2KwvnNZGL4L8V4icj1GtFifD5VjDvRPginYYjS7YXjjv+hZGRNx4A+hiLf2suh > PxDR+u0OC836d7fxWF2jjyOO9UwhUTeu/TGPEF8XWHJ7jls+qUhahTm7Q7tBfI76 > komQgPzFImX2y3ceT4dcmv0ZZtoVJkYlMUxCVUUlDvAwdL9YNUbZZcjyOV9ydNrT > J4FSfvZB1YO2chQT4z2J2P1FrW+TjrHkvONldShs8SCivnmGAc2rQ29yX3DtuPYE > m6ukiz+c8TS4veOmw1RBNXBZ5/w6DCrW5oKdCRQmv3t4D468Vet5zx4tA79QvZOI > uQ4= > -----END CERTIFICATE----- > > > >> >> Also, do you have the current Root CA's certificate stored as >> a trusted CA within DogTag's cert-store, and within the >> web-server with which you are trying to establish an SSL >> connection? > Yes and no. I've tried manually installing the root cert into the > /var/lib/<instance>/alias cert databases, but I still get a failure > when I try and do: > > certutil -V -u V -d . -n <server cert instance> > > Connection with "openssl s_client ..." to this CA shows a chain of a > single cert representing the server. > > If I generate the sub ca under the same security zone as previously > generated Dogtag root CA the certs are set up properly and > automatically. "openssl s_client ...." connecting to this CA shows a > chain of 3 certs as expected. > > On my side, I have the root cert in my browser and trusted. > > > Looking at the /var/lib/<instance>/logs/debug - I find > > [04/Apr/2010:17:47:10][http-9447-Processor18]: CertRequestPanel: > importCertChain > : Exception: java.security.cert.CertificateEncodingException: > Security library f > ailed to decode certificate package: (-8183) security library: > improperly format > ted DER-encoded message. > > But comparing the PKCS7 I generate (using bouncycastle) with the > chains output from Dogtag for the other working sub CA and using > dumpasn1 - I can't tell the difference. Also, certutil seems to be > able to handle the parsing. > > *sigh* > > Mike > > >> >> Arshad Noor >> StrongAuth, Inc. >> >> Michael StJohns wrote: >>> Hi - >>> >>> One of my customers has an existing root key pair and CA cert that >>> exists outside of Dogtag. I want to create a CA immediately >>> subordinate to that root CA and use Dogtag for it. >>> >>> After numerous attempts to adopt Dogtag to an external CA, I admit >>> to defeat. I've tried this with and without a PKCS7 chain, I've >>> tried various extensions and formats for the new CA cert, etc. >>> >>> The CA system comes up, looks good, but looking at the SSL hand >>> shake with "openssl s_client" shows that the server isn't providing >>> the entire chain, only the certificate for the server itself. >>> >>> Taking all of the certs in the chain from root through server and >>> running them through the Java cert path checking routines seems to >>> indicate the certs are fine. >>> >>> >>> If I build a system from scratch - with a new root cert and key >>> pair in one CA and then build a subordinate CA under that in the >>> same domain it works perfectly. >>> >>> Has anyone else tried this? If so, can you give me a step-by-step >>> please? >>> >>> Help! >>> >>> Mike >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >

On 4/4/2010 6:37 PM, Arshad Noor wrote: > I believe your problem may be due to the fact that your self-signed > Root CA certificate does not contain the AuthorityKeyIdentifier (AKI) > extension - it only has the SubjectKeyIdentifier (SKI) extension. > I tried issuing a new root cert with the AKI (and then doing a rebuild of the whole CA) - no luck. But thanks for the suggestion. But - I did find out why my chain wasn't being accepted. It turns out that even though step 3 requires an armored Base64 value (e.g. -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----), step 2 only wants the unarmored Base64 value of the PKCS7 chain object. It also doesn't appear to care whether or not the chain contains the new CA certificate for this instance. At least now the certs are ending up in the database even if the chains still don't seem to work.

Hi Mike, You mention that 2) The PKCS7 chain for step 2 is base 64 encoded, but NOT armored. What do you mean by "Not armored"? Thanks, Erwin