Creating a sub-ca under an external CA?
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
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@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
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@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@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. RFC 5280 -
The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted.
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.
I don't think I understand this. Without an AKI, and with Subject == Issuer you assume this cert was signed by the private key associated with the public key. Indeed, you won't chain any further. If this assumption is false - because you signed it with a different key from a superior - possibly non-self-signed intermediate cert, you don't have sufficient information to complete the chain. So this is a fail - invalid, not a fail -valid scenario.
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.
According to a note from someone at Redhat on the list back in 2008 the "chain" that gets pasted in should only be the chain of the superior issuer and not contain the new cert. So that's just a single certificate - the root. For openssl - the tags in PEM have to change from "CERTIFICATE CHAIN" to "PKCS7" for openssl to recognize it. Mike
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@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. I'm going to - tomorrow - try and replicate exactly the extensions and settings as generated for Root and CA that are wholly Dogtag in certs that I genrate. It shouldn't be this difficult. Part of the issue is that there isn't enough feedback or checking for this branch of the setup scripts... When I do "certutil -V -u V -d . -n "Server-Cert <instance>" in the <instance>/alias directory I still get a certutil -V -u V -d . -n "Server-Cert cert-fake" certutil: certificate is invalid: Peer's Certificate issuer is not recognized. Mike
OK - just for the record - I did figure out the problem. Here are the notes I have from this process. 1) AKI at the root doesn't matter 2) The PKCS7 chain for step 2 is base 64 encoded, but NOT armored. This needs to be documented - ideally in the box used to paste the chain. 3) The chain does not need to include the current (new cert), just the chain of certs for the issuing CA. 4) When the setup routine generates the subsidiary certificates - including the server cert - it appears to use the name in the certificate request as the issuer name for the subsidiary certificates, rather than the subject name of the cert issued by the superior CA. This was the thing that was causing me problems - my certificate signing tool was re-writing the requested name to add things like the country code and the subsidiary certs couldn't chain because of a name mismatch. I think (4) is actually a bug in Dogtag - but I need to do some code reading to confirm my analysis. AFAIK the name in a CSR is just the proposed name - the issuing CA has every right to change the name to meet its requirements. Thanks for the help... Mike On 4/4/2010 9:43 PM, Michael StJohns wrote:
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 -------------------------------------------------- From: "Michael StJohns" <msj@nthpermutation.com> Sent: Monday, April 05, 2010 8:31 PM To: "Arshad Noor" <arshad.noor@strongauth.com> Cc: <pki-users@redhat.com> Subject: Re: [Pki-users] Creating a sub-ca under an external CA?
OK - just for the record - I did figure out the problem. Here are the notes I have from this process.
1) AKI at the root doesn't matter 2) The PKCS7 chain for step 2 is base 64 encoded, but NOT armored. This needs to be documented - ideally in the box used to paste the chain. 3) The chain does not need to include the current (new cert), just the chain of certs for the issuing CA. 4) When the setup routine generates the subsidiary certificates - including the server cert - it appears to use the name in the certificate request as the issuer name for the subsidiary certificates, rather than the subject name of the cert issued by the superior CA. This was the thing that was causing me problems - my certificate signing tool was re-writing the requested name to add things like the country code and the subsidiary certs couldn't chain because of a name mismatch.
I think (4) is actually a bug in Dogtag - but I need to do some code reading to confirm my analysis. AFAIK the name in a CSR is just the proposed name - the issuing CA has every right to change the name to meet its requirements.
Thanks for the help...
Mike
On 4/4/2010 9:43 PM, Michael StJohns wrote:
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.
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
On 4/6/2010 11:04 PM, Erwin Himawan wrote:
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
Armored would be -----BEGIN PKCS7----- or -----BEGIN CERTIFICATE CHAIN----- <base64 stuff> -----END PKCS7----- or -----END CERTIFICATE CHAIN----- Unarmored is just the base64 without the beginning and ending sentinels. Mike
participants (3)
-
Arshad Noor -
Erwin Himawan -
Michael StJohns