From msj at nthpermutation.com Sun Apr 4 21:26:24 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Sun, 04 Apr 2010 17:26:24 -0400 Subject: [Pki-users] Creating a sub-ca under an external CA? Message-ID: <4BB90400.8010001@nthpermutation.com> 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 From arshad.noor at strongauth.com Sun Apr 4 21:58:06 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Sun, 04 Apr 2010 14:58:06 -0700 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: <4BB90400.8010001@nthpermutation.com> References: <4BB90400.8010001@nthpermutation.com> Message-ID: <4BB90B6E.7010208@strongauth.com> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From msj at nthpermutation.com Sun Apr 4 22:12:48 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Sun, 04 Apr 2010 18:12:48 -0400 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: <4BB90B6E.7010208@strongauth.com> References: <4BB90400.8010001@nthpermutation.com> <4BB90B6E.7010208@strongauth.com> Message-ID: <4BB90EE0.3070105@nthpermutation.com> 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//alias cert databases, but I still get a failure when I try and do: certutil -V -u V -d . -n 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//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 at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Sun Apr 4 22:37:47 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Sun, 04 Apr 2010 15:37:47 -0700 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: <4BB90EE0.3070105@nthpermutation.com> References: <4BB90400.8010001@nthpermutation.com> <4BB90B6E.7010208@strongauth.com> <4BB90EE0.3070105@nthpermutation.com> Message-ID: <4BB914BB.3020906@strongauth.com> 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//alias cert databases, but I still get a failure when > I try and do: > > certutil -V -u V -d . -n > > 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//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 at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users > From msj at nthpermutation.com Sun Apr 4 22:47:56 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Sun, 04 Apr 2010 18:47:56 -0400 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: <4BB914BB.3020906@strongauth.com> References: <4BB90400.8010001@nthpermutation.com> <4BB90B6E.7010208@strongauth.com> <4BB90EE0.3070105@nthpermutation.com> <4BB914BB.3020906@strongauth.com> Message-ID: <4BB9171C.1000500@nthpermutation.com> 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//alias cert databases, but I still get a failure >> when I try and do: >> >> certutil -V -u V -d . -n >> >> 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//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 at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >> From msj at nthpermutation.com Mon Apr 5 01:43:30 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Sun, 04 Apr 2010 21:43:30 -0400 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: <4BB914BB.3020906@strongauth.com> References: <4BB90400.8010001@nthpermutation.com> <4BB90B6E.7010208@strongauth.com> <4BB90EE0.3070105@nthpermutation.com> <4BB914BB.3020906@strongauth.com> Message-ID: <4BB94042.9060407@nthpermutation.com> 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 " in the /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 From msj at nthpermutation.com Tue Apr 6 01:31:19 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Mon, 05 Apr 2010 21:31:19 -0400 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: <4BB94042.9060407@nthpermutation.com> References: <4BB90400.8010001@nthpermutation.com> <4BB90B6E.7010208@strongauth.com> <4BB90EE0.3070105@nthpermutation.com> <4BB914BB.3020906@strongauth.com> <4BB94042.9060407@nthpermutation.com> Message-ID: <4BBA8EE7.20809@nthpermutation.com> 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. > From arshad.noor at strongauth.com Tue Apr 6 17:34:20 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 06 Apr 2010 10:34:20 -0700 Subject: [Pki-users] Questions on customizing certificate profiles Message-ID: <4BBB709C.5000409@strongauth.com> Hi, I thought I used to know the Certificate Server, but it appears that so much has changed that I feel like I'm starting over again. Hopefully, I'm the one who's making mistakes and that DogTag is really not different from RHCS. In trying to install DogTag on Fedora 11 (x86_64), I'm unable to customize the initial certificates created by the installation process. For example, here is what I'm doing: 1) Run "yum install pki-ca". 2) Run "pkicreate" with appropriate parameters. 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg files to do the following: - Add "default.params.signingAlg=SHA256withRSA" to the files; - Remove digitalSignature and nonRepudiation for CA cert; - Remove digitalSignature, nonRepudiation, dataEncipherment for Server cert; - Change default validity periods, etc. Yet, none of the certificates generated by the installation process have these changes in them. I've tried stopping "pki-cad", copying the modified *.cfg files to the appropriate "/profiles/ca" directory and restarting pki-cad in case the service needed to see the modified files at startup - but to no avail. I've tried modifying the *.profile files in the /etc/ directory, but to no avail. How does one customize the certificates before the self-signed cert is generated? I'm going through the PDF documentation for RHCS 8.0 and assuming that the instructions there apply to DogTag too. The version number of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 repository. Thanks. Arshad Noor StrongAuth, Inc. From arshad.noor at strongauth.com Tue Apr 6 17:40:17 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 06 Apr 2010 10:40:17 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBB709C.5000409@strongauth.com> References: <4BBB709C.5000409@strongauth.com> Message-ID: <4BBB7201.3@strongauth.com> One more bit of information; in addition to adding the "default.params.signingAlg" parameter, I also modified the following parameters in caCACert.cfg, but I still keep getting SHA1withRSA; none of my changes are picked up in the self-signed cert: policyset.caCertSet.9.constraint.class_id=signingAlgConstraintImpl policyset.caCertSet.9.constraint.name=No Constraint policyset.caCertSet.9.constraint.params.signingAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withEC,SHA512withEC policyset.caCertSet.9.default.class_id=signingAlgDefaultImpl policyset.caCertSet.9.default.name=Signing Alg policyset.caCertSet.9.default.params.signingAlg=SHA256withRSA Arshad Noor StrongAuth, Inc. Arshad Noor wrote: > Hi, > > I thought I used to know the Certificate Server, but it appears > that so much has changed that I feel like I'm starting over again. > Hopefully, I'm the one who's making mistakes and that DogTag is > really not different from RHCS. > > In trying to install DogTag on Fedora 11 (x86_64), I'm unable to > customize the initial certificates created by the installation > process. For example, here is what I'm doing: > > 1) Run "yum install pki-ca". > 2) Run "pkicreate" with appropriate parameters. > 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg > files to do the following: > > - Add "default.params.signingAlg=SHA256withRSA" to the files; > - Remove digitalSignature and nonRepudiation for CA cert; > - Remove digitalSignature, nonRepudiation, dataEncipherment > for Server cert; > - Change default validity periods, etc. > > Yet, none of the certificates generated by the installation process > have these changes in them. > > I've tried stopping "pki-cad", copying the modified *.cfg files to > the appropriate "/profiles/ca" directory and restarting > pki-cad in case the service needed to see the modified files at > startup - but to no avail. > > I've tried modifying the *.profile files in the /etc/ > directory, but to no avail. > > How does one customize the certificates before the self-signed cert > is generated? > > I'm going through the PDF documentation for RHCS 8.0 and assuming > that the instructions there apply to DogTag too. The version number > of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 > repository. > > Thanks. > > Arshad Noor > StrongAuth, Inc. > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From msauton at redhat.com Tue Apr 6 18:04:21 2010 From: msauton at redhat.com (Marc Sauton) Date: Tue, 06 Apr 2010 11:04:21 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBB7201.3@strongauth.com> References: <4BBB709C.5000409@strongauth.com> <4BBB7201.3@strongauth.com> Message-ID: <4BBB77A5.50409@redhat.com> For this first CA, what about changing the pre-op settings in the main config file, like: preop.cert.signing.defaultSigningAlgorithm=SHA1withRSA --> preop.cert.signing.defaultSigningAlgorithm=SHA256withRSA ? M. On 04/06/2010 10:40 AM, Arshad Noor wrote: > One more bit of information; in addition to adding the > "default.params.signingAlg" parameter, I also modified the > following parameters in caCACert.cfg, but I still keep > getting SHA1withRSA; none of my changes are picked up in > the self-signed cert: > > policyset.caCertSet.9.constraint.class_id=signingAlgConstraintImpl > policyset.caCertSet.9.constraint.name=No Constraint > policyset.caCertSet.9.constraint.params.signingAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withEC,SHA512withEC > > policyset.caCertSet.9.default.class_id=signingAlgDefaultImpl > policyset.caCertSet.9.default.name=Signing Alg > policyset.caCertSet.9.default.params.signingAlg=SHA256withRSA > > Arshad Noor > StrongAuth, Inc. > > Arshad Noor wrote: >> Hi, >> >> I thought I used to know the Certificate Server, but it appears >> that so much has changed that I feel like I'm starting over again. >> Hopefully, I'm the one who's making mistakes and that DogTag is >> really not different from RHCS. >> >> In trying to install DogTag on Fedora 11 (x86_64), I'm unable to >> customize the initial certificates created by the installation >> process. For example, here is what I'm doing: >> >> 1) Run "yum install pki-ca". >> 2) Run "pkicreate" with appropriate parameters. >> 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg >> files to do the following: >> >> - Add "default.params.signingAlg=SHA256withRSA" to the files; >> - Remove digitalSignature and nonRepudiation for CA cert; >> - Remove digitalSignature, nonRepudiation, dataEncipherment >> for Server cert; >> - Change default validity periods, etc. >> >> Yet, none of the certificates generated by the installation process >> have these changes in them. >> >> I've tried stopping "pki-cad", copying the modified *.cfg files to >> the appropriate "/profiles/ca" directory and restarting >> pki-cad in case the service needed to see the modified files at >> startup - but to no avail. >> >> I've tried modifying the *.profile files in the /etc/ >> directory, but to no avail. >> >> How does one customize the certificates before the self-signed cert >> is generated? >> >> I'm going through the PDF documentation for RHCS 8.0 and assuming >> that the instructions there apply to DogTag too. The version number >> of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 >> repository. >> >> Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6650 bytes Desc: S/MIME Cryptographic Signature URL: From jmagne at redhat.com Tue Apr 6 18:13:25 2010 From: jmagne at redhat.com (John Magne) Date: Tue, 6 Apr 2010 14:13:25 -0400 (EDT) Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <1425214374.700651270577412091.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> Message-ID: <608343914.701031270577605121.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> Did you try modifying the source of the files in /var/lib/pki-ca/conf/*.profile ?? When an instance is created, I believe the files are taken from here: /usr/share/pki/ca/conf/*.profile I imagine if you change the files in /var/lib/pki-ca/conf before proceeding with the wizard, things should work. Perhaps the files are cached into memory as soon as the instance is created and before the wizard is executed. ----- Original Message ----- From: "Arshad Noor" To: pki-users at redhat.com Sent: Tuesday, April 6, 2010 10:34:20 AM GMT -08:00 US/Canada Pacific Subject: [Pki-users] Questions on customizing certificate profiles Hi, I thought I used to know the Certificate Server, but it appears that so much has changed that I feel like I'm starting over again. Hopefully, I'm the one who's making mistakes and that DogTag is really not different from RHCS. In trying to install DogTag on Fedora 11 (x86_64), I'm unable to customize the initial certificates created by the installation process. For example, here is what I'm doing: 1) Run "yum install pki-ca". 2) Run "pkicreate" with appropriate parameters. 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg files to do the following: - Add "default.params.signingAlg=SHA256withRSA" to the files; - Remove digitalSignature and nonRepudiation for CA cert; - Remove digitalSignature, nonRepudiation, dataEncipherment for Server cert; - Change default validity periods, etc. Yet, none of the certificates generated by the installation process have these changes in them. I've tried stopping "pki-cad", copying the modified *.cfg files to the appropriate "/profiles/ca" directory and restarting pki-cad in case the service needed to see the modified files at startup - but to no avail. I've tried modifying the *.profile files in the /etc/ directory, but to no avail. How does one customize the certificates before the self-signed cert is generated? I'm going through the PDF documentation for RHCS 8.0 and assuming that the instructions there apply to DogTag too. The version number of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 repository. Thanks. Arshad Noor StrongAuth, Inc. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From sean.veale at gdc4s.com Tue Apr 6 18:36:35 2010 From: sean.veale at gdc4s.com (Veale, Sean) Date: Tue, 6 Apr 2010 14:36:35 -0400 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <608343914.701031270577605121.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> References: <1425214374.700651270577412091.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> <608343914.701031270577605121.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> Message-ID: <5E904A528F23FA469961CECAC5F417870252C1EA@NDHMC4SXCH.gdc4s.com> I think the original self-signed cert is created when pkicreate is run, but the actual set of profiles used during the wizard is the *.profile files in the /var/lib/pki-ca/conf/ folder that was mentioned For the other subsystems (DRM, TKS, TPS, never looked at the RA or OCSP systems) it uses the caInternalAuth*.cfg files in /var/lib/pki-ca/profiles/ca folder for the subsystem certs (signing, subsystem, ocsp certs ect) and the /var/lib/pki-ca/profiles/ca/adminCert.profile for the software admin certs loaded into your browser when running the wizards. -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of John Magne Sent: Tuesday, April 06, 2010 2:13 PM To: Arshad Noor Cc: pki-users at redhat.com Subject: Re: [Pki-users] Questions on customizing certificate profiles Did you try modifying the source of the files in /var/lib/pki-ca/conf/*.profile ?? When an instance is created, I believe the files are taken from here: /usr/share/pki/ca/conf/*.profile I imagine if you change the files in /var/lib/pki-ca/conf before proceeding with the wizard, things should work. Perhaps the files are cached into memory as soon as the instance is created and before the wizard is executed. ----- Original Message ----- From: "Arshad Noor" To: pki-users at redhat.com Sent: Tuesday, April 6, 2010 10:34:20 AM GMT -08:00 US/Canada Pacific Subject: [Pki-users] Questions on customizing certificate profiles Hi, I thought I used to know the Certificate Server, but it appears that so much has changed that I feel like I'm starting over again. Hopefully, I'm the one who's making mistakes and that DogTag is really not different from RHCS. In trying to install DogTag on Fedora 11 (x86_64), I'm unable to customize the initial certificates created by the installation process. For example, here is what I'm doing: 1) Run "yum install pki-ca". 2) Run "pkicreate" with appropriate parameters. 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg files to do the following: - Add "default.params.signingAlg=SHA256withRSA" to the files; - Remove digitalSignature and nonRepudiation for CA cert; - Remove digitalSignature, nonRepudiation, dataEncipherment for Server cert; - Change default validity periods, etc. Yet, none of the certificates generated by the installation process have these changes in them. I've tried stopping "pki-cad", copying the modified *.cfg files to the appropriate "/profiles/ca" directory and restarting pki-cad in case the service needed to see the modified files at startup - but to no avail. I've tried modifying the *.profile files in the /etc/ directory, but to no avail. How does one customize the certificates before the self-signed cert is generated? I'm going through the PDF documentation for RHCS 8.0 and assuming that the instructions there apply to DogTag too. The version number of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 repository. Thanks. Arshad Noor StrongAuth, Inc. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Tue Apr 6 18:58:36 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 06 Apr 2010 11:58:36 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBB77A5.50409@redhat.com> References: <4BBB709C.5000409@strongauth.com> <4BBB7201.3@strongauth.com> <4BBB77A5.50409@redhat.com> Message-ID: <4BBB845C.5080805@strongauth.com> So, despite changing CS.cfg in /usr/share/pki/ca/conf to: -------------------- preop.cert.signing.defaultSigningAlgorithm=SHA256withRSA preop.cert.audit_signing.defaultSigningAlgorithm=SHA256withRSA preop.cert.ocsp_signing.defaultSigningAlgorithm=SHA256withRSA preop.cert.sslserver.defaultSigningAlgorithm=SHA256withRSA preop.cert.subsystem.defaultSigningAlgorithm=SHA256withRSA preop.cert.admin.defaultSigningAlgorithm=SHA256withRSA ca.Policy.rule.SigningAlgRule.algorithms=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withEC,SHA512withEC ca.crl.MasterCRL.signingAlgorithm=SHA256withRSA ca.ocsp_signing.defaultSigningAlgorithm=SHA256withRSA -------------------- I still get SHA1 signature algorithms in all certs. I also noticed that when the instance CS.cfg is created in the /etc/ directory, strangely, it has the following: -------------------- # grep SHA /etc/rootca/CS.cfg ca.Policy.rule.SigningAlgRule.algorithms=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withEC,SHA512withEC ca.crl.MasterCRL.signingAlgorithm=SHA1withRSA ca.ocsp_signing.defaultSigningAlgorithm=SHA1withRSA ca.scep.hashAlgorithm=SHA1 ca.signing.defaultSigningAlgorithm=SHA1withRSA preop.cert.admin.defaultSigningAlgorithm=SHA256withRSA preop.cert.audit_signing.defaultSigningAlgorithm=SHA256withRSA preop.cert.ocsp_signing.defaultSigningAlgorithm=SHA256withRSA preop.cert.signing.defaultSigningAlgorithm=SHA256withRSA preop.cert.sslserver.defaultSigningAlgorithm=SHA256withRSA preop.cert.subsystem.defaultSigningAlgorithm=SHA256withRSA -------------------- Notice that despite preop.cert.signing.defaultSigningAlgorithm having SHA256withRSA as a value, the instance CS.cfg now has ca.signing.defaultSigningAlgorithm as SHA1withRSA. Where did this get picked up from? I almost feel like I'm playing a game of "Chutes & Ladders" with the same paramters in .profiles, .cfg, CS.cfg and who knows where else. I will now try the next suggestion and see where it takes me. Thanks. Arshad Noor StrongAuth, Inc. Marc Sauton wrote: > For this first CA, what about changing the pre-op settings in the main > config file, like: > preop.cert.signing.defaultSigningAlgorithm=SHA1withRSA > --> > preop.cert.signing.defaultSigningAlgorithm=SHA256withRSA > ? > M. > > On 04/06/2010 10:40 AM, Arshad Noor wrote: >> One more bit of information; in addition to adding the >> "default.params.signingAlg" parameter, I also modified the >> following parameters in caCACert.cfg, but I still keep >> getting SHA1withRSA; none of my changes are picked up in >> the self-signed cert: >> >> policyset.caCertSet.9.constraint.class_id=signingAlgConstraintImpl >> policyset.caCertSet.9.constraint.name=No Constraint >> policyset.caCertSet.9.constraint.params.signingAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withEC,SHA512withEC >> >> policyset.caCertSet.9.default.class_id=signingAlgDefaultImpl >> policyset.caCertSet.9.default.name=Signing Alg >> policyset.caCertSet.9.default.params.signingAlg=SHA256withRSA >> >> Arshad Noor >> StrongAuth, Inc. >> >> Arshad Noor wrote: >>> Hi, >>> >>> I thought I used to know the Certificate Server, but it appears >>> that so much has changed that I feel like I'm starting over again. >>> Hopefully, I'm the one who's making mistakes and that DogTag is >>> really not different from RHCS. >>> >>> In trying to install DogTag on Fedora 11 (x86_64), I'm unable to >>> customize the initial certificates created by the installation >>> process. For example, here is what I'm doing: >>> >>> 1) Run "yum install pki-ca". >>> 2) Run "pkicreate" with appropriate parameters. >>> 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg >>> files to do the following: >>> >>> - Add "default.params.signingAlg=SHA256withRSA" to the files; >>> - Remove digitalSignature and nonRepudiation for CA cert; >>> - Remove digitalSignature, nonRepudiation, dataEncipherment >>> for Server cert; >>> - Change default validity periods, etc. >>> >>> Yet, none of the certificates generated by the installation process >>> have these changes in them. >>> >>> I've tried stopping "pki-cad", copying the modified *.cfg files to >>> the appropriate "/profiles/ca" directory and restarting >>> pki-cad in case the service needed to see the modified files at >>> startup - but to no avail. >>> >>> I've tried modifying the *.profile files in the /etc/ >>> directory, but to no avail. >>> >>> How does one customize the certificates before the self-signed cert >>> is generated? >>> >>> I'm going through the PDF documentation for RHCS 8.0 and assuming >>> that the instructions there apply to DogTag too. The version number >>> of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 >>> repository. >>> >>> Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > From arshad.noor at strongauth.com Tue Apr 6 19:00:56 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 06 Apr 2010 12:00:56 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <5E904A528F23FA469961CECAC5F417870252C1EA@NDHMC4SXCH.gdc4s.com> References: <1425214374.700651270577412091.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> <608343914.701031270577605121.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> <5E904A528F23FA469961CECAC5F417870252C1EA@NDHMC4SXCH.gdc4s.com> Message-ID: <4BBB84E8.9090203@strongauth.com> The self-signed cert cannot be created at pkicreate, Sean; this is because the DN of the cert and keysize is only specified in the wizard - which is a step well after the pkicreate step. Thanks for the suggestion, though. Arshad Noor StrongAuth, Inc. Veale, Sean wrote: > I think the original self-signed cert is created when pkicreate is run, > but the actual set of profiles used during the wizard is the *.profile > files in the /var/lib/pki-ca/conf/ folder that was mentioned > From awnuk at redhat.com Tue Apr 6 20:37:33 2010 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 06 Apr 2010 13:37:33 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBB709C.5000409@strongauth.com> References: <4BBB709C.5000409@strongauth.com> Message-ID: <4BBB9B8D.1070700@redhat.com> Arshad, You could try renewal called "Renew certificate to be manually approved by agents". Customize your certificate using agent approval page and import new certificate to NSS-DB. Andrew On 04/06/10 10:34, Arshad Noor wrote: > Hi, > > I thought I used to know the Certificate Server, but it appears > that so much has changed that I feel like I'm starting over again. > Hopefully, I'm the one who's making mistakes and that DogTag is > really not different from RHCS. > > In trying to install DogTag on Fedora 11 (x86_64), I'm unable to > customize the initial certificates created by the installation > process. For example, here is what I'm doing: > > 1) Run "yum install pki-ca". > 2) Run "pkicreate" with appropriate parameters. > 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg > files to do the following: > > - Add "default.params.signingAlg=SHA256withRSA" to the files; > - Remove digitalSignature and nonRepudiation for CA cert; > - Remove digitalSignature, nonRepudiation, dataEncipherment > for Server cert; > - Change default validity periods, etc. > > Yet, none of the certificates generated by the installation process > have these changes in them. > > I've tried stopping "pki-cad", copying the modified *.cfg files to > the appropriate "/profiles/ca" directory and restarting > pki-cad in case the service needed to see the modified files at > startup - but to no avail. > > I've tried modifying the *.profile files in the /etc/ > directory, but to no avail. > > How does one customize the certificates before the self-signed cert > is generated? > > I'm going through the PDF documentation for RHCS 8.0 and assuming > that the instructions there apply to DogTag too. The version number > of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 > repository. > > Thanks. > > Arshad Noor > StrongAuth, Inc. > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Tue Apr 6 23:28:33 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 06 Apr 2010 16:28:33 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBB9B8D.1070700@redhat.com> References: <4BBB709C.5000409@strongauth.com> <4BBB9B8D.1070700@redhat.com> Message-ID: <4BBBC3A1.60307@strongauth.com> Its a possibility it could work, Andrew, but it seems like a rather convoluted way to get a straightforward task done. I fear for the issues that I might run into with that process. Am I the only one who is building a PKI with DogTag without the use of SHA1? Seems hard to comprehend given that NIST has recommended for the last 2 years that all new implementations avoid SHA1, and to not use it starting Jan 2011. Arshad Noor StrongAuth, Inc. Andrew Wnuk wrote: > Arshad, > > You could try renewal called "Renew certificate to be manually approved > by agents". Customize your certificate using agent approval page and > import new certificate to NSS-DB. > > Andrew > > On 04/06/10 10:34, Arshad Noor wrote: >> Hi, >> >> I thought I used to know the Certificate Server, but it appears >> that so much has changed that I feel like I'm starting over again. >> Hopefully, I'm the one who's making mistakes and that DogTag is >> really not different from RHCS. >> >> In trying to install DogTag on Fedora 11 (x86_64), I'm unable to >> customize the initial certificates created by the installation >> process. For example, here is what I'm doing: >> >> 1) Run "yum install pki-ca". >> 2) Run "pkicreate" with appropriate parameters. >> 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg >> files to do the following: >> >> - Add "default.params.signingAlg=SHA256withRSA" to the files; >> - Remove digitalSignature and nonRepudiation for CA cert; >> - Remove digitalSignature, nonRepudiation, dataEncipherment >> for Server cert; >> - Change default validity periods, etc. >> >> Yet, none of the certificates generated by the installation process >> have these changes in them. >> >> I've tried stopping "pki-cad", copying the modified *.cfg files to >> the appropriate "/profiles/ca" directory and restarting >> pki-cad in case the service needed to see the modified files at >> startup - but to no avail. >> >> I've tried modifying the *.profile files in the /etc/ >> directory, but to no avail. >> >> How does one customize the certificates before the self-signed cert >> is generated? >> >> I'm going through the PDF documentation for RHCS 8.0 and assuming >> that the instructions there apply to DogTag too. The version number >> of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 >> repository. >> >> Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > From ckannan at redhat.com Tue Apr 6 23:53:23 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Tue, 06 Apr 2010 16:53:23 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBBC3A1.60307@strongauth.com> References: <4BBB709C.5000409@strongauth.com> <4BBB9B8D.1070700@redhat.com> <4BBBC3A1.60307@strongauth.com> Message-ID: <4BBBC973.7090907@redhat.com> On 04/06/2010 04:28 PM, Arshad Noor wrote: > Its a possibility it could work, Andrew, but it seems like a > rather convoluted way to get a straightforward task done. I > fear for the issues that I might run into with that process. > > Am I the only one who is building a PKI with DogTag without > the use of SHA1? Seems hard to comprehend given that NIST has > recommended for the last 2 years that all new implementations > avoid SHA1, and to not use it starting Jan 2011. > > Arshad Noor > StrongAuth, Inc. > > > Andrew Wnuk wrote: >> Arshad, >> >> You could try renewal called "Renew certificate to be manually >> approved by agents". Customize your certificate using agent approval >> page and import new certificate to NSS-DB. >> >> Andrew >> >> On 04/06/10 10:34, Arshad Noor wrote: >>> Hi, >>> >>> I thought I used to know the Certificate Server, but it appears >>> that so much has changed that I feel like I'm starting over again. >>> Hopefully, I'm the one who's making mistakes and that DogTag is >>> really not different from RHCS. >>> >>> In trying to install DogTag on Fedora 11 (x86_64), I'm unable to >>> customize the initial certificates created by the installation >>> process. For example, here is what I'm doing: >>> >>> 1) Run "yum install pki-ca". >>> 2) Run "pkicreate" with appropriate parameters. >>> 3) Modify the caCACert.cfg, caServerCert.cfg and all caInternal*.cfg >>> files to do the following: >>> >>> - Add "default.params.signingAlg=SHA256withRSA" to the files; >>> - Remove digitalSignature and nonRepudiation for CA cert; >>> - Remove digitalSignature, nonRepudiation, dataEncipherment >>> for Server cert; >>> - Change default validity periods, etc. >>> >>> Yet, none of the certificates generated by the installation process >>> have these changes in them. >>> >>> I've tried stopping "pki-cad", copying the modified *.cfg files to >>> the appropriate "/profiles/ca" directory and restarting >>> pki-cad in case the service needed to see the modified files at >>> startup - but to no avail. >>> >>> I've tried modifying the *.profile files in the /etc/ >>> directory, but to no avail. >>> >>> How does one customize the certificates before the self-signed cert >>> is generated? >>> >>> I'm going through the PDF documentation for RHCS 8.0 and assuming >>> that the instructions there apply to DogTag too. The version number >>> of pki-ca I'm picking up is 1.3.2 even though I've specified the 1.2.0 >>> repository. the installation wizard should provide 'options' under the advanced section for you to be able to select the alg to use. Have you tried doing Step (8) from here ? http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configuring_a_CA.html >>> >>> Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >> > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Wed Apr 7 00:08:13 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 06 Apr 2010 17:08:13 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBBC973.7090907@redhat.com> References: <4BBB709C.5000409@strongauth.com> <4BBB9B8D.1070700@redhat.com> <4BBBC3A1.60307@strongauth.com> <4BBBC973.7090907@redhat.com> Message-ID: <4BBBCCED.5040309@strongauth.com> The only option that is visible under Advanced is the key-size for each of the certificate-types. The hash algorithm does not show up at all. Even the default, as mentioned by Step 8, is not the default as the last 10-12 installs have shown: * SHA256withRSA (the default) So, the question is: is the current build of DogTag in the pki repository identical to RHCS 8.0 or is it a different version? Arshad Noor StrongAuth, Inc. Chandrasekar Kannan wrote: > > the installation wizard should provide 'options' under the advanced > section for you to be able to select the alg to use. Have you tried > doing Step (8) from here ? > http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configuring_a_CA.html > From ckannan at redhat.com Wed Apr 7 01:27:04 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Tue, 06 Apr 2010 18:27:04 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBBCCED.5040309@strongauth.com> References: <4BBB709C.5000409@strongauth.com> <4BBB9B8D.1070700@redhat.com> <4BBBC3A1.60307@strongauth.com> <4BBBC973.7090907@redhat.com> <4BBBCCED.5040309@strongauth.com> Message-ID: <4BBBDF68.5030209@redhat.com> On 04/06/2010 05:08 PM, Arshad Noor wrote: > The only option that is visible under Advanced is the key-size > for each of the certificate-types. The hash algorithm does not > show up at all. > > Even the default, as mentioned by Step 8, is not the default as > the last 10-12 installs have shown: > > * SHA256withRSA (the default) > > So, the question is: is the current build of DogTag in the pki > repository identical to RHCS 8.0 or is it a different version? It might very well be ... we can look at the svn commits to be really sure... > > Arshad Noor > StrongAuth, Inc. > > Chandrasekar Kannan wrote: >> >> the installation wizard should provide 'options' under the advanced >> section for you to be able to select the alg to use. Have you tried >> doing Step (8) from here ? >> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configuring_a_CA.html >> From ehimawan at gmail.com Wed Apr 7 01:28:07 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Tue, 6 Apr 2010 20:28:07 -0500 Subject: [Pki-users] Submitting CMCRequest using HttpClient Message-ID: Hi All, I am trying to use HttpClient to submit a CMC request. So far, I have no luck. Each time, I do HttpClient, the server responses with http 404. Anybody has ever tried this? My questions is: could I use HttpClient to submit a CMC request and obtain a CMC response (a certificate?) Here are my procedures: 1. Use certutil to create a CSR 2. Use CMCRequest to create a CMC request message The CMCRequest.cfg content numRequests=1 input=crmf1 output=cmcReq nickname=RA Administrator dbdir=/home/RAagent password= format=pkcs10 3. Use HttpClient to submit the request My HttpClient.cfg contents: host=ca.hh.org port=9180 secure=false input=cmcReq output=cmcResp servlet=/ca/profileSubmitCMCFull Thanks, Erwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ckannan at redhat.com Wed Apr 7 01:50:02 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Tue, 06 Apr 2010 18:50:02 -0700 Subject: [Pki-users] Submitting CMCRequest using HttpClient In-Reply-To: References: Message-ID: <4BBBE4CA.5010906@redhat.com> On 04/06/2010 06:28 PM, Erwin Himawan wrote: > Hi All, > > I am trying to use HttpClient to submit a CMC request. So far, I have > no luck. Each time, I do HttpClient, the server responses with http 404. > > Anybody has ever tried this? > > My questions is: could I use HttpClient to submit a CMC request and > obtain a CMC response (a certificate?) > > Here are my procedures: > 1. Use certutil to create a CSR > 2. Use CMCRequest to create a CMC request message > The CMCRequest.cfg content > numRequests=1 > input=crmf1 > output=cmcReq > nickname=RA Administrator > dbdir=/home/RAagent > password= > format=pkcs10 > 3. Use HttpClient to submit the request > My HttpClient.cfg contents: > host=ca.hh.org > port=9180 > secure=false > input=cmcReq > output=cmcResp > servlet=/ca/profileSubmitCMCFull > I have previously had success with a httpclient.cfg like this... host=qe-blade-13.idm.lab.bos.redhat.com port=23543 secure=true password=redhat input=/root/tmp1/cmcrequest.der output=/root/tmp1/cmcresponse.der dbdir=/root/tmp1/ clientmode=true nickname=CA Administrator of Instance rhpki-ca1's Idm Lab Bos Redhat Domainmitm ID servlet=/ca/ee/ca/profileSubmitCMCFull > Thanks, > Erwin > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehimawan at gmail.com Wed Apr 7 03:04:09 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Tue, 6 Apr 2010 22:04:09 -0500 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: <4BBA8EE7.20809@nthpermutation.com> References: <4BB90400.8010001@nthpermutation.com><4BB90B6E.7010208@strongauth.com><4BB90EE0.3070105@nthpermutation.com><4BB914BB.3020906@strongauth.com><4BB94042.9060407@nthpermutation.com> <4BBA8EE7.20809@nthpermutation.com> Message-ID: 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" Sent: Monday, April 05, 2010 8:31 PM To: "Arshad Noor" Cc: 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 at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From msj at nthpermutation.com Wed Apr 7 03:06:33 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Tue, 06 Apr 2010 23:06:33 -0400 Subject: [Pki-users] Creating a sub-ca under an external CA? In-Reply-To: References: <4BB90400.8010001@nthpermutation.com><4BB90B6E.7010208@strongauth.com><4BB90EE0.3070105@nthpermutation.com><4BB914BB.3020906@strongauth.com><4BB94042.9060407@nthpermutation.com> <4BBA8EE7.20809@nthpermutation.com> Message-ID: <4BBBF6B9.8050907@nthpermutation.com> 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----- -----END PKCS7----- or -----END CERTIFICATE CHAIN----- Unarmored is just the base64 without the beginning and ending sentinels. Mike From ehimawan at gmail.com Wed Apr 7 21:41:52 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Wed, 7 Apr 2010 16:41:52 -0500 Subject: [Pki-users] Submitting CMCRequest using HttpClient In-Reply-To: <4BBBE4CA.5010906@redhat.com> References: <4BBBE4CA.5010906@redhat.com> Message-ID: Hi Chandrasekar, I modified my HttpClient.cfg following your config file; i.e. the servlet parameter: servlet=/ca/ee/ca/profileSubmitCMCFull. The server responded with id-cct-PKIResponse as I expected. I have to look further to investigate why the response I got from the server indicates "Invalid Credential". Thanks again. Erwin On Tue, Apr 6, 2010 at 8:50 PM, Chandrasekar Kannan wrote: > On 04/06/2010 06:28 PM, Erwin Himawan wrote: > > Hi All, > > I am trying to use HttpClient to submit a CMC request. So far, I have no > luck. Each time, I do HttpClient, the server responses with http 404. > > Anybody has ever tried this? > > My questions is: could I use HttpClient to submit a CMC request and > obtain a CMC response (a certificate?) > > Here are my procedures: > 1. Use certutil to create a CSR > 2. Use CMCRequest to create a CMC request message > The CMCRequest.cfg content > numRequests=1 > input=crmf1 > output=cmcReq > nickname=RA Administrator > dbdir=/home/RAagent > password= > format=pkcs10 > 3. Use HttpClient to submit the request > My HttpClient.cfg contents: > host=ca.hh.org > port=9180 > secure=false > input=cmcReq > output=cmcResp > servlet=/ca/profileSubmitCMCFull > > > I have previously had success with a httpclient.cfg like this... > > host=qe-blade-13.idm.lab.bos.redhat.com > port=23543 > secure=true > password=redhat > input=/root/tmp1/cmcrequest.der > output=/root/tmp1/cmcresponse.der > dbdir=/root/tmp1/ > clientmode=true > nickname=CA Administrator of Instance rhpki-ca1's Idm Lab Bos Redhat > Domainmitm ID > servlet=/ca/ee/ca/profileSubmitCMCFull > > > Thanks, > Erwin > > > _______________________________________________ > Pki-users mailing listPki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.burtchen at gmx.de Thu Apr 8 01:32:22 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Thu, 8 Apr 2010 03:32:22 +0200 Subject: [Pki-users] Questions on customizing certificate profiles Message-ID: <201004080332.22976.o.burtchen@gmx.de> Hi @ all, I also tried to change from "SHA1withRSA" to "SHA256withRSA" by editing the config files. No luck! I found, this is hard-coded in the sources, for example in: - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java - pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java Just look for "SHA1withRSA" in the files, I don't think this are just fallbacks. Best regards, Oli Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: > On 04/06/2010 05:08 PM, Arshad Noor wrote: > > The only option that is visible under Advanced is the key-size > > for each of the certificate-types. The hash algorithm does not > > show up at all. > > > > Even the default, as mentioned by Step 8, is not the default as > > the last 10-12 installs have shown: > > > > * SHA256withRSA (the default) > > > > So, the question is: is the current build of DogTag in the pki > > repository identical to RHCS 8.0 or is it a different version? > > It might very well be ... we can look at the svn commits > to be really sure... > > > Arshad Noor > > StrongAuth, Inc. > > > > Chandrasekar Kannan wrote: > >> the installation wizard should provide 'options' under the advanced > >> section for you to be able to select the alg to use. Have you tried > >> doing Step (8) from here ? > >> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configur > >>ing_a_CA.html > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -- Oliver Burtchen, Berlin From arshad.noor at strongauth.com Thu Apr 8 17:55:15 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 08 Apr 2010 10:55:15 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <201004080332.22976.o.burtchen@gmx.de> References: <201004080332.22976.o.burtchen@gmx.de> Message-ID: <4BBE1883.7000805@strongauth.com> Can someone from the DogTag Engineering team confirm that a PKI with only SHA-2 hashes *cannot* be built with the current version of the product? I find this hard to believe given that the RHCS documentation seems to indicate that it is possible to do so, and given that the underlying code already has SHA-2 support; nevertheless, can someone confirm Oliver's finding? Thanks. Arshad Noor StrongAuth, Inc. P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes can be configured at the time the self-signed cert is created, does that imply that the commercial RHCS is technologically different from the open-source DogTag? And, that it isn't just a question of RedHat support? Oliver Burtchen wrote: > Hi @ all, > > I also tried to change from "SHA1withRSA" to "SHA256withRSA" by editing the > config files. No luck! > > I found, this is hard-coded in the sources, for example in: > > - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java > - pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java > > Just look for "SHA1withRSA" in the files, I don't think this are just > fallbacks. > > Best regards, > Oli > > > > Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>> The only option that is visible under Advanced is the key-size >>> for each of the certificate-types. The hash algorithm does not >>> show up at all. >>> >>> Even the default, as mentioned by Step 8, is not the default as >>> the last 10-12 installs have shown: >>> >>> * SHA256withRSA (the default) >>> >>> So, the question is: is the current build of DogTag in the pki >>> repository identical to RHCS 8.0 or is it a different version? >> It might very well be ... we can look at the svn commits >> to be really sure... >> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> Chandrasekar Kannan wrote: >>>> the installation wizard should provide 'options' under the advanced >>>> section for you to be able to select the alg to use. Have you tried >>>> doing Step (8) from here ? >>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configur >>>> ing_a_CA.html >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> > From kevinu at redhat.com Thu Apr 8 18:51:14 2010 From: kevinu at redhat.com (Kevin Unthank) Date: Thu, 08 Apr 2010 11:51:14 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE1883.7000805@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> Message-ID: <4BBE25A2.9020805@redhat.com> Hi Arshad, Obviously, there are differences between RHCS8 and the latest release of Dogtag. Generally, new feature development takes place in dogtag and some of those features find there way back into RHCS8. Bug fixing often occurs first in RHCS8 and those fixes are ported to dogtag. PKI with only SHA-2 hashes is a fix that was made in the RHCS8 code tree and released in both source binary form in errata RHBA-2009-1602. That fix will make it into dogtag builds but I can't commit to a specific release or date when this will happen. Until then it should be possible to work around the problem by using pkisilent or the renewal method suggested by Andrew. Cheers, Kev On 04/08/2010 10:55 AM, Arshad Noor wrote: > Can someone from the DogTag Engineering team confirm that a PKI > with only SHA-2 hashes *cannot* be built with the current version > of the product? > > I find this hard to believe given that the RHCS documentation seems > to indicate that it is possible to do so, and given that the > underlying code already has SHA-2 support; nevertheless, can someone > confirm Oliver's finding? Thanks. > > Arshad Noor > StrongAuth, Inc. > > P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes > can be configured at the time the self-signed cert is created, does > that imply that the commercial RHCS is technologically different from > the open-source DogTag? And, that it isn't just a question of RedHat > support? > > > Oliver Burtchen wrote: >> Hi @ all, >> >> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by >> editing the config files. No luck! >> >> I found, this is hard-coded in the sources, for example in: >> >> - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java >> - pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java >> >> Just look for "SHA1withRSA" in the files, I don't think this are just >> fallbacks. >> Best regards, >> Oli >> >> >> >> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >>> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>>> The only option that is visible under Advanced is the key-size >>>> for each of the certificate-types. The hash algorithm does not >>>> show up at all. >>>> >>>> Even the default, as mentioned by Step 8, is not the default as >>>> the last 10-12 installs have shown: >>>> >>>> * SHA256withRSA (the default) >>>> >>>> So, the question is: is the current build of DogTag in the pki >>>> repository identical to RHCS 8.0 or is it a different version? >>> It might very well be ... we can look at the svn commits >>> to be really sure... >>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> Chandrasekar Kannan wrote: >>>>> the installation wizard should provide 'options' under the advanced >>>>> section for you to be able to select the alg to use. Have you tried >>>>> doing Step (8) from here ? >>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configur >>>>> >>>>> ing_a_CA.html >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >>> >> > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From o.burtchen at gmx.de Thu Apr 8 20:12:40 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Thu, 8 Apr 2010 22:12:40 +0200 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE25A2.9020805@redhat.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> Message-ID: <201004082212.40830.o.burtchen@gmx.de> Hi Kevin, thanks for making the differences plain. For me RHBA-2009-1602 is more a new feature, than a bug fix, but okay. ;-) It seems that pkisilent does not offer an option to change the hash to SHA-2, and as I wrote earlier, IMHO it is volitional hard-coded. Most of the rest of dogtag has code to work with SHA-2. I will give the "renewal method" a try. Best regards, Oli Am Donnerstag, 8. April 2010 20:51:14 schrieb Kevin Unthank: > Hi Arshad, > > Obviously, there are differences between RHCS8 and the latest release > of Dogtag. Generally, new feature development takes place in dogtag > and some of those features find there way back into RHCS8. Bug fixing > often occurs first in RHCS8 and those fixes are ported to dogtag. > > PKI with only SHA-2 hashes is a fix that was made in the RHCS8 > code tree and released in both source binary form in errata > RHBA-2009-1602. That fix will make it into dogtag builds but I can't > commit to a specific release or date when this will happen. > > Until then it should be possible to work around the problem by using > pkisilent or the renewal method suggested by Andrew. > > Cheers, > Kev > > On 04/08/2010 10:55 AM, Arshad Noor wrote: > > Can someone from the DogTag Engineering team confirm that a PKI > > with only SHA-2 hashes *cannot* be built with the current version > > of the product? > > > > I find this hard to believe given that the RHCS documentation seems > > to indicate that it is possible to do so, and given that the > > underlying code already has SHA-2 support; nevertheless, can someone > > confirm Oliver's finding? Thanks. > > > > Arshad Noor > > StrongAuth, Inc. > > > > P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes > > can be configured at the time the self-signed cert is created, does > > that imply that the commercial RHCS is technologically different from > > the open-source DogTag? And, that it isn't just a question of RedHat > > support? > > > > Oliver Burtchen wrote: > >> Hi @ all, > >> > >> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by > >> editing the config files. No luck! > >> > >> I found, this is hard-coded in the sources, for example in: > >> > >> - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java > >> - pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java > >> > >> Just look for "SHA1withRSA" in the files, I don't think this are just > >> fallbacks. > >> Best regards, > >> Oli > >> > >> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: > >>> On 04/06/2010 05:08 PM, Arshad Noor wrote: > >>>> The only option that is visible under Advanced is the key-size > >>>> for each of the certificate-types. The hash algorithm does not > >>>> show up at all. > >>>> > >>>> Even the default, as mentioned by Step 8, is not the default as > >>>> the last 10-12 installs have shown: > >>>> > >>>> * SHA256withRSA (the default) > >>>> > >>>> So, the question is: is the current build of DogTag in the pki > >>>> repository identical to RHCS 8.0 or is it a different version? > >>> > >>> It might very well be ... we can look at the svn commits > >>> to be really sure... > >>> > >>>> Arshad Noor > >>>> StrongAuth, Inc. > >>>> > >>>> Chandrasekar Kannan wrote: > >>>>> the installation wizard should provide 'options' under the advanced > >>>>> section for you to be able to select the alg to use. Have you tried > >>>>> doing Step (8) from here ? > >>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Confi > >>>>>gur > >>>>> > >>>>> ing_a_CA.html > >>> > >>> _______________________________________________ > >>> Pki-users mailing list > >>> Pki-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/pki-users > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -- Oliver Burtchen, Berlin From o.burtchen at gmx.de Thu Apr 8 21:27:18 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Thu, 8 Apr 2010 23:27:18 +0200 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <201004082212.40830.o.burtchen@gmx.de> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE25A2.9020805@redhat.com> <201004082212.40830.o.burtchen@gmx.de> Message-ID: <201004082327.19031.o.burtchen@gmx.de> Just for the record, the "renewal method" seems to work, but it is very annoying. I would be very glad to see the possibility to change the hash-alg as on option to pkicreate, in the wizard or pkisilent. This is a feature-request. ;-) Best regards, Oli Am Donnerstag, 8. April 2010 22:12:40 schrieb Oliver Burtchen: > Hi Kevin, > > thanks for making the differences plain. For me RHBA-2009-1602 is more a > new feature, than a bug fix, but okay. ;-) > > It seems that pkisilent does not offer an option to change the hash to > SHA-2, and as I wrote earlier, IMHO it is volitional hard-coded. Most of > the rest of dogtag has code to work with SHA-2. > > I will give the "renewal method" a try. > > Best regards, > Oli > > Am Donnerstag, 8. April 2010 20:51:14 schrieb Kevin Unthank: > > Hi Arshad, > > > > Obviously, there are differences between RHCS8 and the latest release > > of Dogtag. Generally, new feature development takes place in dogtag > > and some of those features find there way back into RHCS8. Bug fixing > > often occurs first in RHCS8 and those fixes are ported to dogtag. > > > > PKI with only SHA-2 hashes is a fix that was made in the RHCS8 > > code tree and released in both source binary form in errata > > RHBA-2009-1602. That fix will make it into dogtag builds but I can't > > commit to a specific release or date when this will happen. > > > > Until then it should be possible to work around the problem by using > > pkisilent or the renewal method suggested by Andrew. > > > > Cheers, > > Kev > > > > On 04/08/2010 10:55 AM, Arshad Noor wrote: > > > Can someone from the DogTag Engineering team confirm that a PKI > > > with only SHA-2 hashes *cannot* be built with the current version > > > of the product? > > > > > > I find this hard to believe given that the RHCS documentation seems > > > to indicate that it is possible to do so, and given that the > > > underlying code already has SHA-2 support; nevertheless, can someone > > > confirm Oliver's finding? Thanks. > > > > > > Arshad Noor > > > StrongAuth, Inc. > > > > > > P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes > > > can be configured at the time the self-signed cert is created, does > > > that imply that the commercial RHCS is technologically different from > > > the open-source DogTag? And, that it isn't just a question of RedHat > > > support? > > > > > > Oliver Burtchen wrote: > > >> Hi @ all, > > >> > > >> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by > > >> editing the config files. No luck! > > >> > > >> I found, this is hard-coded in the sources, for example in: > > >> > > >> - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java > > >> - > > >> pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java > > >> > > >> Just look for "SHA1withRSA" in the files, I don't think this are just > > >> fallbacks. > > >> Best regards, > > >> Oli > > >> > > >> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: > > >>> On 04/06/2010 05:08 PM, Arshad Noor wrote: > > >>>> The only option that is visible under Advanced is the key-size > > >>>> for each of the certificate-types. The hash algorithm does not > > >>>> show up at all. > > >>>> > > >>>> Even the default, as mentioned by Step 8, is not the default as > > >>>> the last 10-12 installs have shown: > > >>>> > > >>>> * SHA256withRSA (the default) > > >>>> > > >>>> So, the question is: is the current build of DogTag in the pki > > >>>> repository identical to RHCS 8.0 or is it a different version? > > >>> > > >>> It might very well be ... we can look at the svn commits > > >>> to be really sure... > > >>> > > >>>> Arshad Noor > > >>>> StrongAuth, Inc. > > >>>> > > >>>> Chandrasekar Kannan wrote: > > >>>>> the installation wizard should provide 'options' under the advanced > > >>>>> section for you to be able to select the alg to use. Have you tried > > >>>>> doing Step (8) from here ? > > >>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Con > > >>>>>fi gur > > >>>>> > > >>>>> ing_a_CA.html > > >>> > > >>> _______________________________________________ > > >>> Pki-users mailing list > > >>> Pki-users at redhat.com > > >>> https://www.redhat.com/mailman/listinfo/pki-users > > > > > > _______________________________________________ > > > Pki-users mailing list > > > Pki-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-users > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > -- Oliver Burtchen, Berlin From arshad.noor at strongauth.com Thu Apr 8 21:43:22 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 08 Apr 2010 14:43:22 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <201004082327.19031.o.burtchen@gmx.de> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE25A2.9020805@redhat.com> <201004082212.40830.o.burtchen@gmx.de> <201004082327.19031.o.burtchen@gmx.de> Message-ID: <4BBE4DFA.70407@strongauth.com> Oliver, So, what you did was complete the entire process using SHA-1, submit an immediate renewal after modifying the profiles and then install the renewed certificate with SHA-2? A question for Kevin: is this going to require that all the certs generated through the installation process must go through an immediate renewal to get other custom parameters in them? The certs I want have: 1) SHA-256; 2) Custom key-usages - not default for everything; 3) Custom AIA extensions - (did you know that the AIA extension in the OCSP Signing certificate has a pointer to the OCSP URL? I didn't look closely, but I think it may have also been missing the OCSPNoCheck extension - how could OCSP work at all with these defaults?) 4) Custom CPS extensions; 5) Etc. The renewal method essentially forces us to install the PKI twice to get it right, with the additional burden of performing renewals, approvals, replacements, etc. to get the certs right. If there is one tiny error in this additional process, the work just multiplies from there. This is not elegant at all, Kevin. Is there any priority that can be placed towards merging the RHCS code into DogTag and fixing this? Arshad Noor StrongAuth, Inc. Oliver Burtchen wrote: > Just for the record, > > the "renewal method" seems to work, but it is very annoying. I would be very > glad to see the possibility to change the hash-alg as on option to pkicreate, > in the wizard or pkisilent. This is a feature-request. ;-) > > Best regards, > Oli > > > Am Donnerstag, 8. April 2010 22:12:40 schrieb Oliver Burtchen: >> Hi Kevin, >> >> thanks for making the differences plain. For me RHBA-2009-1602 is more a >> new feature, than a bug fix, but okay. ;-) >> >> It seems that pkisilent does not offer an option to change the hash to >> SHA-2, and as I wrote earlier, IMHO it is volitional hard-coded. Most of >> the rest of dogtag has code to work with SHA-2. >> >> I will give the "renewal method" a try. >> >> Best regards, >> Oli >> >> Am Donnerstag, 8. April 2010 20:51:14 schrieb Kevin Unthank: >>> Hi Arshad, >>> >>> Obviously, there are differences between RHCS8 and the latest release >>> of Dogtag. Generally, new feature development takes place in dogtag >>> and some of those features find there way back into RHCS8. Bug fixing >>> often occurs first in RHCS8 and those fixes are ported to dogtag. >>> >>> PKI with only SHA-2 hashes is a fix that was made in the RHCS8 >>> code tree and released in both source binary form in errata >>> RHBA-2009-1602. That fix will make it into dogtag builds but I can't >>> commit to a specific release or date when this will happen. >>> >>> Until then it should be possible to work around the problem by using >>> pkisilent or the renewal method suggested by Andrew. >>> >>> Cheers, >>> Kev >>> >>> On 04/08/2010 10:55 AM, Arshad Noor wrote: >>>> Can someone from the DogTag Engineering team confirm that a PKI >>>> with only SHA-2 hashes *cannot* be built with the current version >>>> of the product? >>>> >>>> I find this hard to believe given that the RHCS documentation seems >>>> to indicate that it is possible to do so, and given that the >>>> underlying code already has SHA-2 support; nevertheless, can someone >>>> confirm Oliver's finding? Thanks. >>>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes >>>> can be configured at the time the self-signed cert is created, does >>>> that imply that the commercial RHCS is technologically different from >>>> the open-source DogTag? And, that it isn't just a question of RedHat >>>> support? >>>> >>>> Oliver Burtchen wrote: >>>>> Hi @ all, >>>>> >>>>> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by >>>>> editing the config files. No luck! >>>>> >>>>> I found, this is hard-coded in the sources, for example in: >>>>> >>>>> - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java >>>>> - >>>>> pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java >>>>> >>>>> Just look for "SHA1withRSA" in the files, I don't think this are just >>>>> fallbacks. >>>>> Best regards, >>>>> Oli >>>>> >>>>> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >>>>>> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>>>>>> The only option that is visible under Advanced is the key-size >>>>>>> for each of the certificate-types. The hash algorithm does not >>>>>>> show up at all. >>>>>>> >>>>>>> Even the default, as mentioned by Step 8, is not the default as >>>>>>> the last 10-12 installs have shown: >>>>>>> >>>>>>> * SHA256withRSA (the default) >>>>>>> >>>>>>> So, the question is: is the current build of DogTag in the pki >>>>>>> repository identical to RHCS 8.0 or is it a different version? >>>>>> It might very well be ... we can look at the svn commits >>>>>> to be really sure... >>>>>> >>>>>>> Arshad Noor >>>>>>> StrongAuth, Inc. >>>>>>> >>>>>>> Chandrasekar Kannan wrote: >>>>>>>> the installation wizard should provide 'options' under the advanced >>>>>>>> section for you to be able to select the alg to use. Have you tried >>>>>>>> doing Step (8) from here ? >>>>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Con >>>>>>>> fi gur >>>>>>>> >>>>>>>> ing_a_CA.html >>>>>> _______________________________________________ >>>>>> Pki-users mailing list >>>>>> Pki-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users > From awnuk at redhat.com Thu Apr 8 21:54:29 2010 From: awnuk at redhat.com (Andrew Wnuk) Date: Thu, 08 Apr 2010 14:54:29 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE4DFA.70407@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE25A2.9020805@redhat.com> <201004082212.40830.o.burtchen@gmx.de> <201004082327.19031.o.burtchen@gmx.de> <4BBE4DFA.70407@strongauth.com> Message-ID: <4BBE5095.80701@redhat.com> On 04/08/2010 02:43 PM, Arshad Noor wrote: > Oliver, > > So, what you did was complete the entire process using SHA-1, > submit an immediate renewal after modifying the profiles and > then install the renewed certificate with SHA-2? > > A question for Kevin: is this going to require that all the > certs generated through the installation process must go > through an immediate renewal to get other custom parameters > in them? The certs I want have: > > 1) SHA-256; > 2) Custom key-usages - not default for everything; > 3) Custom AIA extensions - (did you know that the AIA extension > in the OCSP Signing certificate has a pointer to the OCSP > URL? I didn't look closely, but I think it may have also > been missing the OCSPNoCheck extension - how could OCSP work > at all with these defaults?) > 4) Custom CPS extensions; > 5) Etc. > > The renewal method essentially forces us to install the PKI > twice to get it right, CA installation and certificate renewal are two different processes. > with the additional burden of performing > renewals, approvals, replacements, etc. to get the certs right. > If there is one tiny error in this additional process, the work > just multiplies from there. > > This is not elegant at all, Kevin. > > Is there any priority that can be placed towards merging the RHCS > code into DogTag and fixing this? > > Arshad Noor > StrongAuth, Inc. > > Oliver Burtchen wrote: >> Just for the record, >> >> the "renewal method" seems to work, but it is very annoying. I would >> be very glad to see the possibility to change the hash-alg as on >> option to pkicreate, in the wizard or pkisilent. This is a >> feature-request. ;-) >> >> Best regards, >> Oli >> >> >> Am Donnerstag, 8. April 2010 22:12:40 schrieb Oliver Burtchen: >>> Hi Kevin, >>> >>> thanks for making the differences plain. For me RHBA-2009-1602 is >>> more a >>> new feature, than a bug fix, but okay. ;-) >>> >>> It seems that pkisilent does not offer an option to change the hash to >>> SHA-2, and as I wrote earlier, IMHO it is volitional hard-coded. >>> Most of >>> the rest of dogtag has code to work with SHA-2. >>> >>> I will give the "renewal method" a try. >>> >>> Best regards, >>> Oli >>> >>> Am Donnerstag, 8. April 2010 20:51:14 schrieb Kevin Unthank: >>>> Hi Arshad, >>>> >>>> Obviously, there are differences between RHCS8 and the latest release >>>> of Dogtag. Generally, new feature development takes place in dogtag >>>> and some of those features find there way back into RHCS8. Bug fixing >>>> often occurs first in RHCS8 and those fixes are ported to dogtag. >>>> >>>> PKI with only SHA-2 hashes is a fix that was made in the RHCS8 >>>> code tree and released in both source binary form in errata >>>> RHBA-2009-1602. That fix will make it into dogtag builds but I can't >>>> commit to a specific release or date when this will happen. >>>> >>>> Until then it should be possible to work around the problem by using >>>> pkisilent or the renewal method suggested by Andrew. >>>> >>>> Cheers, >>>> Kev >>>> >>>> On 04/08/2010 10:55 AM, Arshad Noor wrote: >>>>> Can someone from the DogTag Engineering team confirm that a PKI >>>>> with only SHA-2 hashes *cannot* be built with the current version >>>>> of the product? >>>>> >>>>> I find this hard to believe given that the RHCS documentation seems >>>>> to indicate that it is possible to do so, and given that the >>>>> underlying code already has SHA-2 support; nevertheless, can someone >>>>> confirm Oliver's finding? Thanks. >>>>> >>>>> Arshad Noor >>>>> StrongAuth, Inc. >>>>> >>>>> P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes >>>>> can be configured at the time the self-signed cert is created, does >>>>> that imply that the commercial RHCS is technologically different from >>>>> the open-source DogTag? And, that it isn't just a question of RedHat >>>>> support? >>>>> >>>>> Oliver Burtchen wrote: >>>>>> Hi @ all, >>>>>> >>>>>> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by >>>>>> editing the config files. No luck! >>>>>> >>>>>> I found, this is hard-coded in the sources, for example in: >>>>>> >>>>>> - >>>>>> pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java >>>>>> - >>>>>> pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java >>>>>> >>>>>> >>>>>> Just look for "SHA1withRSA" in the files, I don't think this are >>>>>> just >>>>>> fallbacks. >>>>>> Best regards, >>>>>> Oli >>>>>> >>>>>> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >>>>>>> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>>>>>>> The only option that is visible under Advanced is the key-size >>>>>>>> for each of the certificate-types. The hash algorithm does not >>>>>>>> show up at all. >>>>>>>> >>>>>>>> Even the default, as mentioned by Step 8, is not the default as >>>>>>>> the last 10-12 installs have shown: >>>>>>>> >>>>>>>> * SHA256withRSA (the default) >>>>>>>> >>>>>>>> So, the question is: is the current build of DogTag in the pki >>>>>>>> repository identical to RHCS 8.0 or is it a different version? >>>>>>> It might very well be ... we can look at the svn commits >>>>>>> to be really sure... >>>>>>> >>>>>>>> Arshad Noor >>>>>>>> StrongAuth, Inc. >>>>>>>> >>>>>>>> Chandrasekar Kannan wrote: >>>>>>>>> the installation wizard should provide 'options' under the >>>>>>>>> advanced >>>>>>>>> section for you to be able to select the alg to use. Have you >>>>>>>>> tried >>>>>>>>> doing Step (8) from here ? >>>>>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Con >>>>>>>>> >>>>>>>>> fi gur >>>>>>>>> >>>>>>>>> ing_a_CA.html >>>>>>> _______________________________________________ >>>>>>> Pki-users mailing list >>>>>>> Pki-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>>> _______________________________________________ >>>>> Pki-users mailing list >>>>> Pki-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >> > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Thu Apr 8 22:08:10 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 08 Apr 2010 15:08:10 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE5095.80701@redhat.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE25A2.9020805@redhat.com> <201004082212.40830.o.burtchen@gmx.de> <201004082327.19031.o.burtchen@gmx.de> <4BBE4DFA.70407@strongauth.com> <4BBE5095.80701@redhat.com> Message-ID: <4BBE53CA.2020304@strongauth.com> I am aware of that, Andrew. But, if the original installation process does not get me the certificates I want, and I have to "renew" the certificates to get the profile I want, then I am being forced to nearly double the work I have to do just to get the certificates right the first time. Arshad Noor StrongAuth, Inc. Andrew Wnuk wrote: > On 04/08/2010 02:43 PM, Arshad Noor wrote: >> The renewal method essentially forces us to install the PKI >> twice to get it right, > CA installation and certificate renewal are two different processes. From arshad.noor at strongauth.com Thu Apr 8 22:25:24 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 08 Apr 2010 15:25:24 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE25A2.9020805@redhat.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> Message-ID: <4BBE57D4.1040305@strongauth.com> I am sorry to read this, Kevin. It suggests that RedHat has forgotten its open-source roots and what made it a billion dollar company in the first place. We are all familiar with the **** that companies put up with when buying some commercial products. Open-source was meant to be an answer to that problem - that quality could be vastly improved in software when there were many eyes looking at the source - not because some people just like the idea of seeing the source-code of the products they use. That RedHat was making money on services off of open-source products was perfectly acceptable - there is real value in services. But, when the open-source company starts differentiating its open-source products from its commercial products, it subverts the whole notion of open-source and what it stands for. If the fix did not exist and it was up to the open-source community to prioritize the fix, that's one thing. But when the fix *does* exist, and has been merged into the commercial branch, but is not merged into the open-source branch - that suggests deliberate manipulation of the trust and goodwill of the open-source community. Arshad Noor StrongAuth, Inc. Kevin Unthank wrote: > Hi Arshad, > > Obviously, there are differences between RHCS8 and the latest release > of Dogtag. Generally, new feature development takes place in dogtag > and some of those features find there way back into RHCS8. Bug fixing > often occurs first in RHCS8 and those fixes are ported to dogtag. > > PKI with only SHA-2 hashes is a fix that was made in the RHCS8 > code tree and released in both source binary form in errata > RHBA-2009-1602. That fix will make it into dogtag builds but I can't > commit to a specific release or date when this will happen. > > Until then it should be possible to work around the problem by using > pkisilent or the renewal method suggested by Andrew. > > Cheers, > Kev > > On 04/08/2010 10:55 AM, Arshad Noor wrote: >> Can someone from the DogTag Engineering team confirm that a PKI >> with only SHA-2 hashes *cannot* be built with the current version >> of the product? >> >> I find this hard to believe given that the RHCS documentation seems >> to indicate that it is possible to do so, and given that the >> underlying code already has SHA-2 support; nevertheless, can someone >> confirm Oliver's finding? Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes >> can be configured at the time the self-signed cert is created, does >> that imply that the commercial RHCS is technologically different from >> the open-source DogTag? And, that it isn't just a question of RedHat >> support? >> >> >> Oliver Burtchen wrote: >>> Hi @ all, >>> >>> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by >>> editing the config files. No luck! >>> >>> I found, this is hard-coded in the sources, for example in: >>> >>> - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java >>> - pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java >>> >>> Just look for "SHA1withRSA" in the files, I don't think this are just >>> fallbacks. >>> Best regards, >>> Oli >>> >>> >>> >>> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >>>> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>>>> The only option that is visible under Advanced is the key-size >>>>> for each of the certificate-types. The hash algorithm does not >>>>> show up at all. >>>>> >>>>> Even the default, as mentioned by Step 8, is not the default as >>>>> the last 10-12 installs have shown: >>>>> >>>>> * SHA256withRSA (the default) >>>>> >>>>> So, the question is: is the current build of DogTag in the pki >>>>> repository identical to RHCS 8.0 or is it a different version? >>>> It might very well be ... we can look at the svn commits >>>> to be really sure... >>>> >>>>> Arshad Noor >>>>> StrongAuth, Inc. >>>>> >>>>> Chandrasekar Kannan wrote: >>>>>> the installation wizard should provide 'options' under the advanced >>>>>> section for you to be able to select the alg to use. Have you tried >>>>>> doing Step (8) from here ? >>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configur >>>>>> >>>>>> >>>>>> ing_a_CA.html >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> >>> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users From kevinu at redhat.com Thu Apr 8 23:09:23 2010 From: kevinu at redhat.com (Kevin Unthank) Date: Thu, 08 Apr 2010 16:09:23 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE57D4.1040305@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> <4BBE57D4.1040305@strongauth.com> Message-ID: <4BBE6223.3000904@redhat.com> Hi Arshad, We most certainly have not forgotten our open-source roots. In response to customer demand for this SHA2 functionality, Red Hat engineers implemented it and released it as an enhancement errata for RHCS8. At the very same time, the source code for that enhancement was made available, freely, to everyone in the dogtag community. You can checkout that codewith SVN svn co https://pki.fedoraproject.org/svn/pki/branches/PKI_8_0_ERRATA_BRANCH Merge it with the dogtag source and compile your own dogtag packages with the desired functionality. As I stated in my earlier response we absolutely intend to take the code from the open-source CS8 branch, and add it to the open-source dogtag tip but that work has not been scheduled yet. I will see if I can get the priority bumped up. I strongly encourage you to create your own dogtag build environment so you can get access to the latest code checkins. There are instructions for doing this on the dogtag wiki and I know some of the community members have already done this. There is no manipulation of the trust and goodwill of the open-source community going on here. Cheers, Kev On 04/08/2010 03:25 PM, Arshad Noor wrote: > I am sorry to read this, Kevin. It suggests that RedHat has > forgotten its open-source roots and what made it a billion > dollar company in the first place. > > We are all familiar with the **** that companies put up with > when buying some commercial products. Open-source was meant > to be an answer to that problem - that quality could be vastly > improved in software when there were many eyes looking at the > source - not because some people just like the idea of seeing > the source-code of the products they use. > > That RedHat was making money on services off of open-source > products was perfectly acceptable - there is real value in > services. But, when the open-source company starts > differentiating its open-source products from its commercial > products, it subverts the whole notion of open-source and what > it stands for. > > If the fix did not exist and it was up to the open-source > community to prioritize the fix, that's one thing. But when > the fix *does* exist, and has been merged into the commercial > branch, but is not merged into the open-source branch - that > suggests deliberate manipulation of the trust and goodwill of > the open-source community. > > Arshad Noor > StrongAuth, Inc. > > > Kevin Unthank wrote: >> Hi Arshad, >> >> Obviously, there are differences between RHCS8 and the latest release >> of Dogtag. Generally, new feature development takes place in dogtag >> and some of those features find there way back into RHCS8. Bug fixing >> often occurs first in RHCS8 and those fixes are ported to dogtag. >> >> PKI with only SHA-2 hashes is a fix that was made in the RHCS8 >> code tree and released in both source binary form in errata >> RHBA-2009-1602. That fix will make it into dogtag builds but I can't >> commit to a specific release or date when this will happen. >> >> Until then it should be possible to work around the problem by using >> pkisilent or the renewal method suggested by Andrew. >> >> Cheers, >> Kev >> >> On 04/08/2010 10:55 AM, Arshad Noor wrote: >>> Can someone from the DogTag Engineering team confirm that a PKI >>> with only SHA-2 hashes *cannot* be built with the current version >>> of the product? >>> >>> I find this hard to believe given that the RHCS documentation seems >>> to indicate that it is possible to do so, and given that the >>> underlying code already has SHA-2 support; nevertheless, can someone >>> confirm Oliver's finding? Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes >>> can be configured at the time the self-signed cert is created, does >>> that imply that the commercial RHCS is technologically different from >>> the open-source DogTag? And, that it isn't just a question of RedHat >>> support? >>> >>> >>> Oliver Burtchen wrote: >>>> Hi @ all, >>>> >>>> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by >>>> editing the config files. No luck! >>>> >>>> I found, this is hard-coded in the sources, for example in: >>>> >>>> - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java >>>> - >>>> pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java >>>> >>>> Just look for "SHA1withRSA" in the files, I don't think this are just >>>> fallbacks. >>>> Best regards, >>>> Oli >>>> >>>> >>>> >>>> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >>>>> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>>>>> The only option that is visible under Advanced is the key-size >>>>>> for each of the certificate-types. The hash algorithm does not >>>>>> show up at all. >>>>>> >>>>>> Even the default, as mentioned by Step 8, is not the default as >>>>>> the last 10-12 installs have shown: >>>>>> >>>>>> * SHA256withRSA (the default) >>>>>> >>>>>> So, the question is: is the current build of DogTag in the pki >>>>>> repository identical to RHCS 8.0 or is it a different version? >>>>> It might very well be ... we can look at the svn commits >>>>> to be really sure... >>>>> >>>>>> Arshad Noor >>>>>> StrongAuth, Inc. >>>>>> >>>>>> Chandrasekar Kannan wrote: >>>>>>> the installation wizard should provide 'options' under the advanced >>>>>>> section for you to be able to select the alg to use. Have you tried >>>>>>> doing Step (8) from here ? >>>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configur >>>>>>> >>>>>>> >>>>>>> ing_a_CA.html >>>>> _______________________________________________ >>>>> Pki-users mailing list >>>>> Pki-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>>> >>>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users From o.burtchen at gmx.de Thu Apr 8 23:26:30 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Fri, 9 Apr 2010 01:26:30 +0200 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE4DFA.70407@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <201004082327.19031.o.burtchen@gmx.de> <4BBE4DFA.70407@strongauth.com> Message-ID: <201004090126.30512.o.burtchen@gmx.de> Hi @ all, yes, I followed the "normal" installation, than did a renewal like Andrew suggested and installed this cert via pkiconsole. And I also know the difference between CA installation and certificate renewal, this is what we are talking about. I did this only to get SHA-2 certificates, what is currently IMHO not possible with the normal installation of dogtag. Best regards, Oli Am Donnerstag, 8. April 2010 23:43:22 schrieb Arshad Noor: > Oliver, > > So, what you did was complete the entire process using SHA-1, > submit an immediate renewal after modifying the profiles and > then install the renewed certificate with SHA-2? > > A question for Kevin: is this going to require that all the > certs generated through the installation process must go > through an immediate renewal to get other custom parameters > in them? The certs I want have: > > 1) SHA-256; > 2) Custom key-usages - not default for everything; > 3) Custom AIA extensions - (did you know that the AIA extension > in the OCSP Signing certificate has a pointer to the OCSP > URL? I didn't look closely, but I think it may have also > been missing the OCSPNoCheck extension - how could OCSP work > at all with these defaults?) > 4) Custom CPS extensions; > 5) Etc. > > The renewal method essentially forces us to install the PKI > twice to get it right, with the additional burden of performing > renewals, approvals, replacements, etc. to get the certs right. > If there is one tiny error in this additional process, the work > just multiplies from there. > > This is not elegant at all, Kevin. > > Is there any priority that can be placed towards merging the RHCS > code into DogTag and fixing this? > > Arshad Noor > StrongAuth, Inc. > > Oliver Burtchen wrote: > > Just for the record, > > > > the "renewal method" seems to work, but it is very annoying. I would be > > very glad to see the possibility to change the hash-alg as on option to > > pkicreate, in the wizard or pkisilent. This is a feature-request. ;-) > > > > Best regards, > > Oli > > > > Am Donnerstag, 8. April 2010 22:12:40 schrieb Oliver Burtchen: > >> Hi Kevin, > >> > >> thanks for making the differences plain. For me RHBA-2009-1602 is more a > >> new feature, than a bug fix, but okay. ;-) > >> > >> It seems that pkisilent does not offer an option to change the hash to > >> SHA-2, and as I wrote earlier, IMHO it is volitional hard-coded. Most > >> of the rest of dogtag has code to work with SHA-2. > >> > >> I will give the "renewal method" a try. > >> > >> Best regards, > >> Oli > >> > >> Am Donnerstag, 8. April 2010 20:51:14 schrieb Kevin Unthank: > >>> Hi Arshad, > >>> > >>> Obviously, there are differences between RHCS8 and the latest release > >>> of Dogtag. Generally, new feature development takes place in dogtag > >>> and some of those features find there way back into RHCS8. Bug fixing > >>> often occurs first in RHCS8 and those fixes are ported to dogtag. > >>> > >>> PKI with only SHA-2 hashes is a fix that was made in the RHCS8 > >>> code tree and released in both source binary form in errata > >>> RHBA-2009-1602. That fix will make it into dogtag builds but I can't > >>> commit to a specific release or date when this will happen. > >>> > >>> Until then it should be possible to work around the problem by using > >>> pkisilent or the renewal method suggested by Andrew. > >>> > >>> Cheers, > >>> Kev > >>> > >>> On 04/08/2010 10:55 AM, Arshad Noor wrote: > >>>> Can someone from the DogTag Engineering team confirm that a PKI > >>>> with only SHA-2 hashes *cannot* be built with the current version > >>>> of the product? > >>>> > >>>> I find this hard to believe given that the RHCS documentation seems > >>>> to indicate that it is possible to do so, and given that the > >>>> underlying code already has SHA-2 support; nevertheless, can someone > >>>> confirm Oliver's finding? Thanks. > >>>> > >>>> Arshad Noor > >>>> StrongAuth, Inc. > >>>> > >>>> P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes > >>>> can be configured at the time the self-signed cert is created, does > >>>> that imply that the commercial RHCS is technologically different from > >>>> the open-source DogTag? And, that it isn't just a question of RedHat > >>>> support? > >>>> > >>>> Oliver Burtchen wrote: > >>>>> Hi @ all, > >>>>> > >>>>> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by > >>>>> editing the config files. No luck! > >>>>> > >>>>> I found, this is hard-coded in the sources, for example in: > >>>>> > >>>>> - > >>>>> pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java > >>>>> - > >>>>> pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.jav > >>>>>a > >>>>> > >>>>> Just look for "SHA1withRSA" in the files, I don't think this are just > >>>>> fallbacks. > >>>>> Best regards, > >>>>> Oli > >>>>> > >>>>> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: > >>>>>> On 04/06/2010 05:08 PM, Arshad Noor wrote: > >>>>>>> The only option that is visible under Advanced is the key-size > >>>>>>> for each of the certificate-types. The hash algorithm does not > >>>>>>> show up at all. > >>>>>>> > >>>>>>> Even the default, as mentioned by Step 8, is not the default as > >>>>>>> the last 10-12 installs have shown: > >>>>>>> > >>>>>>> * SHA256withRSA (the default) > >>>>>>> > >>>>>>> So, the question is: is the current build of DogTag in the pki > >>>>>>> repository identical to RHCS 8.0 or is it a different version? > >>>>>> > >>>>>> It might very well be ... we can look at the svn commits > >>>>>> to be really sure... > >>>>>> > >>>>>>> Arshad Noor > >>>>>>> StrongAuth, Inc. > >>>>>>> > >>>>>>> Chandrasekar Kannan wrote: > >>>>>>>> the installation wizard should provide 'options' under the > >>>>>>>> advanced section for you to be able to select the alg to use. Have > >>>>>>>> you tried doing Step (8) from here ? > >>>>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Co > >>>>>>>>n fi gur > >>>>>>>> > >>>>>>>> ing_a_CA.html > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Pki-users mailing list > >>>>>> Pki-users at redhat.com > >>>>>> https://www.redhat.com/mailman/listinfo/pki-users > >>>> > >>>> _______________________________________________ > >>>> Pki-users mailing list > >>>> Pki-users at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/pki-users > >>> > >>> _______________________________________________ > >>> Pki-users mailing list > >>> Pki-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/pki-users > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -- Oliver Burtchen, Berlin From arshad.noor at strongauth.com Thu Apr 8 23:33:36 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 08 Apr 2010 16:33:36 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE6223.3000904@redhat.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> <4BBE57D4.1040305@strongauth.com> <4BBE6223.3000904@redhat.com> Message-ID: <4BBE67D0.7040905@strongauth.com> I will give this a shot, Kevin - although I wonder how much time it will take to get the Build environment right to get through all the compiles vs. doing a "renewal" of the certs. However, to follow up on the other issue - the documentation on RHBA-2009-1602 suggests that only the SHA-2 algorithm issue can be fixed. Am I still stuck with the renewal method to get the other certificate extensions fixed - the keyUsages, AIA, OCSPNoCheck, etc? Arshad Noor StrongAuth, Inc. Kevin Unthank wrote: > Hi Arshad, > > We most certainly have not forgotten our open-source roots. > > In response to customer demand for this SHA2 functionality, Red Hat > engineers implemented it and released it as an enhancement errata > for RHCS8. At the very same time, the source code for that > enhancement was made available, freely, to everyone in the dogtag > community. > > You can checkout that codewith SVN > svn co https://pki.fedoraproject.org/svn/pki/branches/PKI_8_0_ERRATA_BRANCH > Merge it with the dogtag source and compile your own dogtag > packages with the desired functionality. > > As I stated in my earlier response we absolutely intend to > take the code from the open-source CS8 branch, and add it to the > open-source dogtag tip but that work has not been scheduled yet. > I will see if I can get the priority bumped up. > > I strongly encourage you to create your own dogtag build > environment so you can get access to the latest code checkins. > There are instructions for doing this on the dogtag wiki and > I know some of the community members have already done this. > > There is no manipulation of the trust and goodwill of the > open-source community going on here. > > Cheers, > Kev > > On 04/08/2010 03:25 PM, Arshad Noor wrote: >> I am sorry to read this, Kevin. It suggests that RedHat has >> forgotten its open-source roots and what made it a billion >> dollar company in the first place. >> >> We are all familiar with the **** that companies put up with >> when buying some commercial products. Open-source was meant >> to be an answer to that problem - that quality could be vastly >> improved in software when there were many eyes looking at the >> source - not because some people just like the idea of seeing >> the source-code of the products they use. >> >> That RedHat was making money on services off of open-source >> products was perfectly acceptable - there is real value in >> services. But, when the open-source company starts >> differentiating its open-source products from its commercial >> products, it subverts the whole notion of open-source and what >> it stands for. >> >> If the fix did not exist and it was up to the open-source >> community to prioritize the fix, that's one thing. But when >> the fix *does* exist, and has been merged into the commercial >> branch, but is not merged into the open-source branch - that >> suggests deliberate manipulation of the trust and goodwill of >> the open-source community. >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> Kevin Unthank wrote: >>> Hi Arshad, >>> >>> Obviously, there are differences between RHCS8 and the latest release >>> of Dogtag. Generally, new feature development takes place in dogtag >>> and some of those features find there way back into RHCS8. Bug fixing >>> often occurs first in RHCS8 and those fixes are ported to dogtag. >>> >>> PKI with only SHA-2 hashes is a fix that was made in the RHCS8 >>> code tree and released in both source binary form in errata >>> RHBA-2009-1602. That fix will make it into dogtag builds but I can't >>> commit to a specific release or date when this will happen. >>> >>> Until then it should be possible to work around the problem by using >>> pkisilent or the renewal method suggested by Andrew. >>> >>> Cheers, >>> Kev >>> >>> On 04/08/2010 10:55 AM, Arshad Noor wrote: >>>> Can someone from the DogTag Engineering team confirm that a PKI >>>> with only SHA-2 hashes *cannot* be built with the current version >>>> of the product? >>>> >>>> I find this hard to believe given that the RHCS documentation seems >>>> to indicate that it is possible to do so, and given that the >>>> underlying code already has SHA-2 support; nevertheless, can someone >>>> confirm Oliver's finding? Thanks. >>>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes >>>> can be configured at the time the self-signed cert is created, does >>>> that imply that the commercial RHCS is technologically different from >>>> the open-source DogTag? And, that it isn't just a question of RedHat >>>> support? >>>> >>>> >>>> Oliver Burtchen wrote: >>>>> Hi @ all, >>>>> >>>>> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by >>>>> editing the config files. No luck! >>>>> >>>>> I found, this is hard-coded in the sources, for example in: >>>>> >>>>> - pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java >>>>> - >>>>> pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java >>>>> >>>>> Just look for "SHA1withRSA" in the files, I don't think this are just >>>>> fallbacks. >>>>> Best regards, >>>>> Oli >>>>> >>>>> >>>>> >>>>> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >>>>>> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>>>>>> The only option that is visible under Advanced is the key-size >>>>>>> for each of the certificate-types. The hash algorithm does not >>>>>>> show up at all. >>>>>>> >>>>>>> Even the default, as mentioned by Step 8, is not the default as >>>>>>> the last 10-12 installs have shown: >>>>>>> >>>>>>> * SHA256withRSA (the default) >>>>>>> >>>>>>> So, the question is: is the current build of DogTag in the pki >>>>>>> repository identical to RHCS 8.0 or is it a different version? >>>>>> It might very well be ... we can look at the svn commits >>>>>> to be really sure... >>>>>> >>>>>>> Arshad Noor >>>>>>> StrongAuth, Inc. >>>>>>> >>>>>>> Chandrasekar Kannan wrote: >>>>>>>> the installation wizard should provide 'options' under the advanced >>>>>>>> section for you to be able to select the alg to use. Have you tried >>>>>>>> doing Step (8) from here ? >>>>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configur >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ing_a_CA.html >>>>>> _______________________________________________ >>>>>> Pki-users mailing list >>>>>> Pki-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users From ckannan at redhat.com Thu Apr 8 23:42:21 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Thu, 08 Apr 2010 16:42:21 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE67D0.7040905@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> <4BBE57D4.1040305@strongauth.com> <4BBE6223.3000904@redhat.com> <4BBE67D0.7040905@strongauth.com> Message-ID: <4BBE69DD.4060501@redhat.com> On 04/08/2010 04:33 PM, Arshad Noor wrote: > I will give this a shot, Kevin - although I wonder how much > time it will take to get the Build environment right to get > through all the compiles vs. doing a "renewal" of the certs. > > However, to follow up on the other issue - the documentation > on RHBA-2009-1602 suggests that only the SHA-2 algorithm issue > can be fixed. Am I still stuck with the renewal method to get > the other certificate extensions fixed - the keyUsages, AIA, > OCSPNoCheck, etc? I don't think so. You should be able to get those customized by editing those profile config files in question before going through the wizard. Sha-2 was a bit hard-coded IIRC , hence it required code changes. > > Arshad Noor > StrongAuth, Inc. > > Kevin Unthank wrote: >> Hi Arshad, >> >> We most certainly have not forgotten our open-source roots. >> >> In response to customer demand for this SHA2 functionality, Red Hat >> engineers implemented it and released it as an enhancement errata >> for RHCS8. At the very same time, the source code for that >> enhancement was made available, freely, to everyone in the dogtag >> community. >> >> You can checkout that codewith SVN >> svn co >> https://pki.fedoraproject.org/svn/pki/branches/PKI_8_0_ERRATA_BRANCH >> Merge it with the dogtag source and compile your own dogtag >> packages with the desired functionality. >> >> As I stated in my earlier response we absolutely intend to >> take the code from the open-source CS8 branch, and add it to the >> open-source dogtag tip but that work has not been scheduled yet. >> I will see if I can get the priority bumped up. >> >> I strongly encourage you to create your own dogtag build >> environment so you can get access to the latest code checkins. >> There are instructions for doing this on the dogtag wiki and >> I know some of the community members have already done this. >> >> There is no manipulation of the trust and goodwill of the >> open-source community going on here. >> >> Cheers, >> Kev >> >> On 04/08/2010 03:25 PM, Arshad Noor wrote: >>> I am sorry to read this, Kevin. It suggests that RedHat has >>> forgotten its open-source roots and what made it a billion >>> dollar company in the first place. >>> >>> We are all familiar with the **** that companies put up with >>> when buying some commercial products. Open-source was meant >>> to be an answer to that problem - that quality could be vastly >>> improved in software when there were many eyes looking at the >>> source - not because some people just like the idea of seeing >>> the source-code of the products they use. >>> >>> That RedHat was making money on services off of open-source >>> products was perfectly acceptable - there is real value in >>> services. But, when the open-source company starts >>> differentiating its open-source products from its commercial >>> products, it subverts the whole notion of open-source and what >>> it stands for. >>> >>> If the fix did not exist and it was up to the open-source >>> community to prioritize the fix, that's one thing. But when >>> the fix *does* exist, and has been merged into the commercial >>> branch, but is not merged into the open-source branch - that >>> suggests deliberate manipulation of the trust and goodwill of >>> the open-source community. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> >>> Kevin Unthank wrote: >>>> Hi Arshad, >>>> >>>> Obviously, there are differences between RHCS8 and the latest release >>>> of Dogtag. Generally, new feature development takes place in dogtag >>>> and some of those features find there way back into RHCS8. Bug fixing >>>> often occurs first in RHCS8 and those fixes are ported to dogtag. >>>> >>>> PKI with only SHA-2 hashes is a fix that was made in the RHCS8 >>>> code tree and released in both source binary form in errata >>>> RHBA-2009-1602. That fix will make it into dogtag builds but I can't >>>> commit to a specific release or date when this will happen. >>>> >>>> Until then it should be possible to work around the problem by using >>>> pkisilent or the renewal method suggested by Andrew. >>>> >>>> Cheers, >>>> Kev >>>> >>>> On 04/08/2010 10:55 AM, Arshad Noor wrote: >>>>> Can someone from the DogTag Engineering team confirm that a PKI >>>>> with only SHA-2 hashes *cannot* be built with the current version >>>>> of the product? >>>>> >>>>> I find this hard to believe given that the RHCS documentation seems >>>>> to indicate that it is possible to do so, and given that the >>>>> underlying code already has SHA-2 support; nevertheless, can someone >>>>> confirm Oliver's finding? Thanks. >>>>> >>>>> Arshad Noor >>>>> StrongAuth, Inc. >>>>> >>>>> P.S. Since the RHCS 8.0 documentation does state that SHA-2 hashes >>>>> can be configured at the time the self-signed cert is created, does >>>>> that imply that the commercial RHCS is technologically different from >>>>> the open-source DogTag? And, that it isn't just a question of RedHat >>>>> support? >>>>> >>>>> >>>>> Oliver Burtchen wrote: >>>>>> Hi @ all, >>>>>> >>>>>> I also tried to change from "SHA1withRSA" to "SHA256withRSA" by >>>>>> editing the config files. No luck! >>>>>> >>>>>> I found, this is hard-coded in the sources, for example in: >>>>>> >>>>>> - >>>>>> pki-common-1.3.2/src/com/netscape/cms/servlet/csadmin/SizePanel.java >>>>>> - >>>>>> pki-common-1.3.2//src/com/netscape/cmscore/security/CASigningCert.java >>>>>> >>>>>> >>>>>> Just look for "SHA1withRSA" in the files, I don't think this are >>>>>> just >>>>>> fallbacks. >>>>>> Best regards, >>>>>> Oli >>>>>> >>>>>> >>>>>> >>>>>> Am Mittwoch, 7. April 2010 03:27:04 schrieb Chandrasekar Kannan: >>>>>>> On 04/06/2010 05:08 PM, Arshad Noor wrote: >>>>>>>> The only option that is visible under Advanced is the key-size >>>>>>>> for each of the certificate-types. The hash algorithm does not >>>>>>>> show up at all. >>>>>>>> >>>>>>>> Even the default, as mentioned by Step 8, is not the default as >>>>>>>> the last 10-12 installs have shown: >>>>>>>> >>>>>>>> * SHA256withRSA (the default) >>>>>>>> >>>>>>>> So, the question is: is the current build of DogTag in the pki >>>>>>>> repository identical to RHCS 8.0 or is it a different version? >>>>>>> It might very well be ... we can look at the svn commits >>>>>>> to be really sure... >>>>>>> >>>>>>>> Arshad Noor >>>>>>>> StrongAuth, Inc. >>>>>>>> >>>>>>>> Chandrasekar Kannan wrote: >>>>>>>>> the installation wizard should provide 'options' under the >>>>>>>>> advanced >>>>>>>>> section for you to be able to select the alg to use. Have you >>>>>>>>> tried >>>>>>>>> doing Step (8) from here ? >>>>>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Configur >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ing_a_CA.html >>>>>>> _______________________________________________ >>>>>>> Pki-users mailing list >>>>>>> Pki-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pki-users mailing list >>>>> Pki-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-users > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Thu Apr 8 23:52:47 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 08 Apr 2010 16:52:47 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE69DD.4060501@redhat.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> <4BBE57D4.1040305@strongauth.com> <4BBE6223.3000904@redhat.com> <4BBE67D0.7040905@strongauth.com> <4BBE69DD.4060501@redhat.com> Message-ID: <4BBE6C4F.1070101@strongauth.com> However, when I did modify the *.cfg files in the profiles/ca directory to customize the extensions, none of the changes were picked up. I've only focused on the SHA-2 issue because that seemed to be symptomatic of the underlying problem - but the real problem is that the entire certificate is not customizable in the installation process. Or, are you suggesting that with the fix compiled in, all the profile changes will get included too? Arshad Noor StrongAuth, Inc. Chandrasekar Kannan wrote: > On 04/08/2010 04:33 PM, Arshad Noor wrote: >> >> However, to follow up on the other issue - the documentation >> on RHBA-2009-1602 suggests that only the SHA-2 algorithm issue >> can be fixed. Am I still stuck with the renewal method to get >> the other certificate extensions fixed - the keyUsages, AIA, >> OCSPNoCheck, etc? > > I don't think so. You should be able to get those customized > by editing those profile config files in question before going > through the wizard. Sha-2 was a bit hard-coded IIRC , hence it > required code changes. From ckannan at redhat.com Fri Apr 9 00:13:31 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Thu, 08 Apr 2010 17:13:31 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE6C4F.1070101@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> <4BBE57D4.1040305@strongauth.com> <4BBE6223.3000904@redhat.com> <4BBE67D0.7040905@strongauth.com> <4BBE69DD.4060501@redhat.com> <4BBE6C4F.1070101@strongauth.com> Message-ID: <4BBE712B.1000400@redhat.com> On 04/08/2010 04:52 PM, Arshad Noor wrote: > However, when I did modify the *.cfg files in the profiles/ca > directory to customize the extensions, none of the changes were > picked up. For the CA, You would need to edit the conf/*.profile files. restart the instance. Go through the wizard and see if your customization's show up. IIRC this should work. --Chandra > I've only focused on the SHA-2 issue because that > seemed to be symptomatic of the underlying problem - but the > real problem is that the entire certificate is not customizable > in the installation process. > > Or, are you suggesting that with the fix compiled in, all the > profile changes will get included too? > > Arshad Noor > StrongAuth, Inc. > > Chandrasekar Kannan wrote: >> On 04/08/2010 04:33 PM, Arshad Noor wrote: >>> >>> However, to follow up on the other issue - the documentation >>> on RHBA-2009-1602 suggests that only the SHA-2 algorithm issue >>> can be fixed. Am I still stuck with the renewal method to get >>> the other certificate extensions fixed - the keyUsages, AIA, >>> OCSPNoCheck, etc? >> >> I don't think so. You should be able to get those customized >> by editing those profile config files in question before going >> through the wizard. Sha-2 was a bit hard-coded IIRC , hence it >> required code changes. From awnuk at redhat.com Fri Apr 9 00:20:31 2010 From: awnuk at redhat.com (Andrew Wnuk) Date: Thu, 08 Apr 2010 17:20:31 -0700 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE6C4F.1070101@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE1883.7000805@strongauth.com> <4BBE25A2.9020805@redhat.com> <4BBE57D4.1040305@strongauth.com> <4BBE6223.3000904@redhat.com> <4BBE67D0.7040905@strongauth.com> <4BBE69DD.4060501@redhat.com> <4BBE6C4F.1070101@strongauth.com> Message-ID: <4BBE72CF.8080408@redhat.com> As I said before, you can also customize your certificate using agent approval page. You need to customize profile only for items that cannot be edited through agent approval UI. On 04/08/2010 04:52 PM, Arshad Noor wrote: > However, when I did modify the *.cfg files in the profiles/ca > directory to customize the extensions, none of the changes were > picked up. I've only focused on the SHA-2 issue because that > seemed to be symptomatic of the underlying problem - but the > real problem is that the entire certificate is not customizable > in the installation process. > > Or, are you suggesting that with the fix compiled in, all the > profile changes will get included too? > > Arshad Noor > StrongAuth, Inc. > > Chandrasekar Kannan wrote: >> On 04/08/2010 04:33 PM, Arshad Noor wrote: >>> >>> However, to follow up on the other issue - the documentation >>> on RHBA-2009-1602 suggests that only the SHA-2 algorithm issue >>> can be fixed. Am I still stuck with the renewal method to get >>> the other certificate extensions fixed - the keyUsages, AIA, >>> OCSPNoCheck, etc? >> >> I don't think so. You should be able to get those customized >> by editing those profile config files in question before going >> through the wizard. Sha-2 was a bit hard-coded IIRC , hence it >> required code changes. > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From o.burtchen at gmx.de Fri Apr 9 00:42:31 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Fri, 9 Apr 2010 02:42:31 +0200 Subject: [Pki-users] Questions on customizing certificate profiles In-Reply-To: <4BBE6C4F.1070101@strongauth.com> References: <201004080332.22976.o.burtchen@gmx.de> <4BBE69DD.4060501@redhat.com> <4BBE6C4F.1070101@strongauth.com> Message-ID: <201004090242.31651.o.burtchen@gmx.de> I agree with Arshad, the /etc//CF.cfg file is overridden, when the "Key Pairs" tab in the wizard is processed, no matter what you say in the *.cfg or *.profiles files before. I will have a look at the SVN-branch like Kevin sugguests tomorrow. But I am afraid that it does not matter. It's a pki.fedoraproject branch. I had looks at rawhide, no difference. For example, search for "SHA1" here. It's still hard coded: https://pki.fedoraproject.org/svn/pki/branches/PKI_8_0_ERRATA_BRANCH/pki/base/common/src/com/netscape/cmscore/security/CASigningCert.java BTW: There are other things which could be easily fixed, but are pending for 2 years, like my last two comments on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=441974 Best regards, Oli Am Freitag, 9. April 2010 01:52:47 schrieb Arshad Noor: > However, when I did modify the *.cfg files in the profiles/ca > directory to customize the extensions, none of the changes were > picked up. I've only focused on the SHA-2 issue because that > seemed to be symptomatic of the underlying problem - but the > real problem is that the entire certificate is not customizable > in the installation process. > > Or, are you suggesting that with the fix compiled in, all the > profile changes will get included too? > > Arshad Noor > StrongAuth, Inc. > > Chandrasekar Kannan wrote: > > On 04/08/2010 04:33 PM, Arshad Noor wrote: > >> However, to follow up on the other issue - the documentation > >> on RHBA-2009-1602 suggests that only the SHA-2 algorithm issue > >> can be fixed. Am I still stuck with the renewal method to get > >> the other certificate extensions fixed - the keyUsages, AIA, > >> OCSPNoCheck, etc? > > > > I don't think so. You should be able to get those customized > > by editing those profile config files in question before going > > through the wizard. Sha-2 was a bit hard-coded IIRC , hence it > > required code changes. > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -- Oliver Burtchen, Berlin From arshad.noor at strongauth.com Sat Apr 10 01:09:01 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Fri, 09 Apr 2010 18:09:01 -0700 Subject: [Pki-users] Missing pki-ca RPM in EPEL Message-ID: <4BBFCFAD.1000005@strongauth.com> Hi, Is there a reason why the pki-ca RPM is missing from the EPEL5 repositories at: http://download.fedora.redhat.com/pub/epel/5/i386/repoview/letter_p.group.html http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/letter_p.group.html http://download.fedora.redhat.com/pub/epel/5/SRPMS/repoview/letter_p.group.html Thanks. Arshad Noor StrongAuth, Inc. From arshad.noor at strongauth.com Fri Apr 16 00:49:44 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 15 Apr 2010 17:49:44 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem Message-ID: <4BC7B428.7060808@strongauth.com> Hi, I've updated DogTag to the current modules available (FC11 x86_64): dogtag-pki-ca-ui-1.3.1-1.fc11.noarch dogtag-pki-common-ui-1.3.1-1.fc11.noarch dogtag-pki-console-ui-1.3.1-1.fc11.noarch pki-ca-1.3.3-1.fc11.noarch pki-common-1.3.3-1.fc11.noarch pki-console-1.3.1-1.fc11.noarch pki-java-tools-1.3.1-1.fc11.noarch pki-native-tools-1.3.0-5.fc11.x86_64 pki-selinux-1.3.4-1.fc11.noarch pki-setup-1.3.4-1.fc11.noarch pki-silent-1.3.2-1.fc11.noarch pki-symkey-1.3.2-3.fc11.x86_64 pki-util-1.3.0-5.fc11.noarch I've installed and successfully tested a Utimaco CryptoServer HSM on the operating system, including adding it to secmod.db (in the /var/lib/subca01/alias directory), generating a RSA key-pair, issuing a self-signed and listing the objects using certutil (the attached hsm-config.txt file shows sample output). I've modified CS.cfg in /etc/subca01 to include this token (as the attached modules.txt file shows). I've even restarted pki-cad services after adding the HSM to secmod.db, to ensure that the DogTag code reads secmod.db with the CryptoServer configured in it. However, when it comes time to install a Subordinate CA, the KeyStore page claims that the Utimaco HSM is not found (see keystore-page.png) even though it is correctly listed on the page under "Supported Security Modules". What am I missing? How do I get DogTag to use the HSM to generate the key-pair? Thanks. Arshad Noor StrongAuth, Inc. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hsm-config.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: modules.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: keystore-page.png Type: image/png Size: 169581 bytes Desc: not available URL: From msj at nthpermutation.com Fri Apr 16 01:21:12 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Thu, 15 Apr 2010 21:21:12 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BC7B428.7060808@strongauth.com> References: <4BC7B428.7060808@strongauth.com> Message-ID: <4BC7BB88.3030905@nthpermutation.com> Any chance you're trying to use the same Slot for multiple CAs? The module listing only shows a single slot. It's possible/probable that won't work. Try initializing a second slot on the UT and try again. Mike On 4/15/2010 8:49 PM, Arshad Noor wrote: > Hi, > > I've updated DogTag to the current modules available (FC11 x86_64): > > dogtag-pki-ca-ui-1.3.1-1.fc11.noarch > dogtag-pki-common-ui-1.3.1-1.fc11.noarch > dogtag-pki-console-ui-1.3.1-1.fc11.noarch > > pki-ca-1.3.3-1.fc11.noarch > pki-common-1.3.3-1.fc11.noarch > pki-console-1.3.1-1.fc11.noarch > pki-java-tools-1.3.1-1.fc11.noarch > pki-native-tools-1.3.0-5.fc11.x86_64 > pki-selinux-1.3.4-1.fc11.noarch > pki-setup-1.3.4-1.fc11.noarch > pki-silent-1.3.2-1.fc11.noarch > pki-symkey-1.3.2-3.fc11.x86_64 > pki-util-1.3.0-5.fc11.noarch > > > I've installed and successfully tested a Utimaco CryptoServer HSM > on the operating system, including adding it to secmod.db (in the > /var/lib/subca01/alias directory), generating a RSA key-pair, > issuing a self-signed and listing the objects using certutil (the > attached hsm-config.txt file shows sample output). > > I've modified CS.cfg in /etc/subca01 to include this token (as the > attached modules.txt file shows). > > I've even restarted pki-cad services after adding the HSM to secmod.db, > to ensure that the DogTag code reads secmod.db with the CryptoServer > configured in it. > > However, when it comes time to install a Subordinate CA, the KeyStore > page claims that the Utimaco HSM is not found (see keystore-page.png) > even though it is correctly listed on the page under "Supported > Security Modules". > > What am I missing? > > How do I get DogTag to use the HSM to generate the key-pair? > > Thanks. > > Arshad Noor > StrongAuth, Inc. > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msj at nthpermutation.com Fri Apr 16 01:45:01 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Thu, 15 Apr 2010 21:45:01 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BC7B428.7060808@strongauth.com> References: <4BC7B428.7060808@strongauth.com> Message-ID: <4BC7C11D.9060209@nthpermutation.com> Sorry - after I sent my earlier email I realized you probably encountered the same problem I did. I need to report the bug to Utimaco/Sophos, but the driver on the 2.01 disk for Linux appears to have problems finding the configuration file in the standard locations. I'm not sure exactly what the problem is. You can duplicate this by clearing the CS2_PKCS11_INI environment variable, placing the cs2_pkcs11.ini file in one of the standard locations - e.g. /usr/etc/cs2_pkcs11.ini and then running the modutil command again over a blank database and try and add the module again. If you get the error CKR_FUNCTION_FAILED - its the same issue. Strangely enough, the config file is found, its just not loaded for some reason. (Do an 'strace' and look at the "access" calls). Mike On 4/15/2010 8:49 PM, Arshad Noor wrote: > Hi, > > I've updated DogTag to the current modules available (FC11 x86_64): > > dogtag-pki-ca-ui-1.3.1-1.fc11.noarch > dogtag-pki-common-ui-1.3.1-1.fc11.noarch > dogtag-pki-console-ui-1.3.1-1.fc11.noarch > > pki-ca-1.3.3-1.fc11.noarch > pki-common-1.3.3-1.fc11.noarch > pki-console-1.3.1-1.fc11.noarch > pki-java-tools-1.3.1-1.fc11.noarch > pki-native-tools-1.3.0-5.fc11.x86_64 > pki-selinux-1.3.4-1.fc11.noarch > pki-setup-1.3.4-1.fc11.noarch > pki-silent-1.3.2-1.fc11.noarch > pki-symkey-1.3.2-3.fc11.x86_64 > pki-util-1.3.0-5.fc11.noarch > > > I've installed and successfully tested a Utimaco CryptoServer HSM > on the operating system, including adding it to secmod.db (in the > /var/lib/subca01/alias directory), generating a RSA key-pair, > issuing a self-signed and listing the objects using certutil (the > attached hsm-config.txt file shows sample output). > > I've modified CS.cfg in /etc/subca01 to include this token (as the > attached modules.txt file shows). > > I've even restarted pki-cad services after adding the HSM to secmod.db, > to ensure that the DogTag code reads secmod.db with the CryptoServer > configured in it. > > However, when it comes time to install a Subordinate CA, the KeyStore > page claims that the Utimaco HSM is not found (see keystore-page.png) > even though it is correctly listed on the page under "Supported > Security Modules". > > What am I missing? > > How do I get DogTag to use the HSM to generate the key-pair? > > Thanks. > > Arshad Noor > StrongAuth, Inc. > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arshad.noor at strongauth.com Fri Apr 16 01:47:58 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 15 Apr 2010 18:47:58 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BC7BB88.3030905@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7BB88.3030905@nthpermutation.com> Message-ID: <4BC7C1CE.2050907@strongauth.com> This is the only CA using the HSM. The TEST Root was setup using the Internal token. Arshad Noor StrongAuth, Inc. Michael StJohns wrote: > Any chance you're trying to use the same Slot for multiple CAs? The > module listing only shows a single slot. It's possible/probable that > won't work. Try initializing a second slot on the UT and try again. > > Mike > > > On 4/15/2010 8:49 PM, Arshad Noor wrote: >> Hi, >> >> I've updated DogTag to the current modules available (FC11 x86_64): >> >> dogtag-pki-ca-ui-1.3.1-1.fc11.noarch >> dogtag-pki-common-ui-1.3.1-1.fc11.noarch >> dogtag-pki-console-ui-1.3.1-1.fc11.noarch >> >> pki-ca-1.3.3-1.fc11.noarch >> pki-common-1.3.3-1.fc11.noarch >> pki-console-1.3.1-1.fc11.noarch >> pki-java-tools-1.3.1-1.fc11.noarch >> pki-native-tools-1.3.0-5.fc11.x86_64 >> pki-selinux-1.3.4-1.fc11.noarch >> pki-setup-1.3.4-1.fc11.noarch >> pki-silent-1.3.2-1.fc11.noarch >> pki-symkey-1.3.2-3.fc11.x86_64 >> pki-util-1.3.0-5.fc11.noarch >> >> >> I've installed and successfully tested a Utimaco CryptoServer HSM >> on the operating system, including adding it to secmod.db (in the >> /var/lib/subca01/alias directory), generating a RSA key-pair, >> issuing a self-signed and listing the objects using certutil (the >> attached hsm-config.txt file shows sample output). >> >> I've modified CS.cfg in /etc/subca01 to include this token (as the >> attached modules.txt file shows). >> >> I've even restarted pki-cad services after adding the HSM to secmod.db, >> to ensure that the DogTag code reads secmod.db with the CryptoServer >> configured in it. >> >> However, when it comes time to install a Subordinate CA, the KeyStore >> page claims that the Utimaco HSM is not found (see keystore-page.png) >> even though it is correctly listed on the page under "Supported >> Security Modules". >> >> What am I missing? >> >> How do I get DogTag to use the HSM to generate the key-pair? >> >> Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Fri Apr 16 01:49:46 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 15 Apr 2010 18:49:46 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BC7C11D.9060209@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> Message-ID: <4BC7C23A.8060706@strongauth.com> So, how did you resolve this, Mike? Or, is it still unresolved? Thanks. Arshad Noor StrongAuth, Inc. Michael StJohns wrote: > Sorry - after I sent my earlier email I realized you probably > encountered the same problem I did. > > I need to report the bug to Utimaco/Sophos, but the driver on the 2.01 > disk for Linux appears to have problems finding the configuration file > in the standard locations. I'm not sure exactly what the problem is. > You can duplicate this by clearing the CS2_PKCS11_INI environment > variable, placing the cs2_pkcs11.ini file in one of the standard > locations - e.g. /usr/etc/cs2_pkcs11.ini and then running the modutil > command again over a blank database and try and add the module again. > If you get the error CKR_FUNCTION_FAILED - its the same issue. > > Strangely enough, the config file is found, its just not loaded for some > reason. (Do an 'strace' and look at the "access" calls). > > Mike > > On 4/15/2010 8:49 PM, Arshad Noor wrote: >> Hi, >> >> I've updated DogTag to the current modules available (FC11 x86_64): >> >> dogtag-pki-ca-ui-1.3.1-1.fc11.noarch >> dogtag-pki-common-ui-1.3.1-1.fc11.noarch >> dogtag-pki-console-ui-1.3.1-1.fc11.noarch >> >> pki-ca-1.3.3-1.fc11.noarch >> pki-common-1.3.3-1.fc11.noarch >> pki-console-1.3.1-1.fc11.noarch >> pki-java-tools-1.3.1-1.fc11.noarch >> pki-native-tools-1.3.0-5.fc11.x86_64 >> pki-selinux-1.3.4-1.fc11.noarch >> pki-setup-1.3.4-1.fc11.noarch >> pki-silent-1.3.2-1.fc11.noarch >> pki-symkey-1.3.2-3.fc11.x86_64 >> pki-util-1.3.0-5.fc11.noarch >> >> >> I've installed and successfully tested a Utimaco CryptoServer HSM >> on the operating system, including adding it to secmod.db (in the >> /var/lib/subca01/alias directory), generating a RSA key-pair, >> issuing a self-signed and listing the objects using certutil (the >> attached hsm-config.txt file shows sample output). >> >> I've modified CS.cfg in /etc/subca01 to include this token (as the >> attached modules.txt file shows). >> >> I've even restarted pki-cad services after adding the HSM to secmod.db, >> to ensure that the DogTag code reads secmod.db with the CryptoServer >> configured in it. >> >> However, when it comes time to install a Subordinate CA, the KeyStore >> page claims that the Utimaco HSM is not found (see keystore-page.png) >> even though it is correctly listed on the page under "Supported >> Security Modules". >> >> What am I missing? >> >> How do I get DogTag to use the HSM to generate the key-pair? >> >> Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Thu Apr 22 19:27:43 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 22 Apr 2010 12:27:43 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BC7C11D.9060209@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> Message-ID: <4BD0A32F.7060800@strongauth.com> Can someone from the DogTag team explain the process by which the installation servlet "finds" PKCS11 modules/HSMs and logs into them? Alternatively, if you can point me to the specific source module that performs this, I'd be happy to look at it myself. I'm still baffled by our inability to have the installation servlet find the Utimaco HSM module, despite the fact that modutil sees it: $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. CryptoServer library name: /usr/bin/libcs2_pkcs11.so slots: 1 slot attached status: loaded slot: CryptoServer Device '/dev/cs2' - Slot No: 0 token: CBUAE TEST ----------------------------------------------------------- There were some SELinux errors, but I fixed all of them; despite all calls now being successful, the installation servlet will still not see the HSM. Thanks. Arshad Noor StrongAuth, Inc. From cfu at redhat.com Thu Apr 22 20:29:48 2010 From: cfu at redhat.com (Christina Fu) Date: Thu, 22 Apr 2010 13:29:48 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0A32F.7060800@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> Message-ID: <4BD0B1BC.3020304@redhat.com> Hi Arshad, Just a thought. Did you try removing the space for your token name? Christina Arshad Noor wrote: > Can someone from the DogTag team explain the process by which > the installation servlet "finds" PKCS11 modules/HSMs and logs > into them? Alternatively, if you can point me to the specific > source module that performs this, I'd be happy to look at it > myself. > > I'm still baffled by our inability to have the installation > servlet find the Utimaco HSM module, despite the fact that > modutil sees it: > > $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. CryptoServer > library name: /usr/bin/libcs2_pkcs11.so > slots: 1 slot attached > status: loaded > > slot: CryptoServer Device '/dev/cs2' - Slot No: 0 > token: CBUAE TEST > ----------------------------------------------------------- > > > There were some SELinux errors, but I fixed all of them; despite > all calls now being successful, the installation servlet will > still not see the HSM. > > Thanks. > > Arshad Noor > StrongAuth, Inc. > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Thu Apr 22 21:06:07 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 22 Apr 2010 14:06:07 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0B1BC.3020304@redhat.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> Message-ID: <4BD0BA3F.6000608@strongauth.com> Hi Christina, Good to hear from you again. I changed the token name and removed the space, but nothing changed, unfortunately: Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. CryptoServer library name: /usr/bin/libcs2_pkcs11.so slots: 1 slot attached status: loaded slot: CryptoServer Device '/dev/cs2' - Slot No: 0 token: CBUAETEST ----------------------------------------------------------- The debug file for the new CA instance shows: ------------------------------------------- [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: display() [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got module NSS Internal PKCS #11 Module [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: supported modules count= 4 [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from config module: NSS Internal PKCS #11 Module [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: module found: NSS Internal PKCS #11 Module [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token nick name=NSS Generic Crypto Services [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token logged in?false [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is present?true [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token NSS Generic Crypto Services not to be added [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token nick name=Internal Key Storage Token [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token logged in?true [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is present?true [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding module NSS Internal PKCS #11 Module [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from config module: nfast [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding module nfast [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from config module: lunasa [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding module lunasa [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from config module: CryptoServer [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding module CryptoServer [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel subpanelno =9 ------------------------------------------- The CS.cfg for this instance has the following: ------------------------------------------- preop.configModules.count=4 ... preop.configModules.module3.commonName=CryptoServer preop.configModules.module3.imagePath=../img/clearpixel.gif preop.configModules.module3.userFriendlyName=Utimacos's CryptoServer Hardware Security Module preop.module.token=CBUAETEST ------------------------------------------- Arshad Noor StrongAuth, Inc. Christina Fu wrote: > Hi Arshad, > > Just a thought. Did you try removing the space for your token name? > > Christina > > Arshad Noor wrote: >> Can someone from the DogTag team explain the process by which >> the installation servlet "finds" PKCS11 modules/HSMs and logs >> into them? Alternatively, if you can point me to the specific >> source module that performs this, I'd be happy to look at it >> myself. >> >> I'm still baffled by our inability to have the installation >> servlet find the Utimaco HSM module, despite the fact that >> modutil sees it: >> >> $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list >> >> Listing of PKCS #11 Modules >> ----------------------------------------------------------- >> 1. NSS Internal PKCS #11 Module >> slots: 2 slots attached >> status: loaded >> >> slot: NSS Internal Cryptographic Services >> token: NSS Generic Crypto Services >> >> slot: NSS User Private Key and Certificate Services >> token: NSS Certificate DB >> >> 2. CryptoServer >> library name: /usr/bin/libcs2_pkcs11.so >> slots: 1 slot attached >> status: loaded >> >> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >> token: CBUAE TEST >> ----------------------------------------------------------- >> >> >> There were some SELinux errors, but I fixed all of them; despite >> all calls now being successful, the installation servlet will >> still not see the HSM. >> >> Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > From cfu at redhat.com Thu Apr 22 21:50:36 2010 From: cfu at redhat.com (Christina Fu) Date: Thu, 22 Apr 2010 14:50:36 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0BA3F.6000608@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> Message-ID: <4BD0C4AC.2010904@redhat.com> Arshad, I'm curious. The unsupported modules are supposed to be picked up by the configuration module. That means, you don't need to add those configModules in the CS.cfg. Can you try doing that? If that works, I'd be interested in knowing if the token name with space contributed to any part of the issue too. Chistina Arshad Noor wrote: > Hi Christina, > > Good to hear from you again. > > I changed the token name and removed the space, but nothing changed, > unfortunately: > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. CryptoServer > library name: /usr/bin/libcs2_pkcs11.so > slots: 1 slot attached > status: loaded > > slot: CryptoServer Device '/dev/cs2' - Slot No: 0 > token: CBUAETEST > ----------------------------------------------------------- > > The debug file for the new CA instance shows: > > ------------------------------------------- > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: display() > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got > module NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: supported > modules count= 4 > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: module > found: NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > nick name=NSS Generic Crypto Services > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > logged in?false > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is > present?true > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token NSS > Generic Crypto Services not to be added > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > nick name=Internal Key Storage Token > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token > logged in?true > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is > present?true > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module NSS Internal PKCS #11 Module > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: nfast > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module nfast > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: lunasa > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module lunasa > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from > config module: CryptoServer > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding > module CryptoServer > [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel subpanelno =9 > ------------------------------------------- > > The CS.cfg for this instance has the following: > > ------------------------------------------- > preop.configModules.count=4 > ... > preop.configModules.module3.commonName=CryptoServer > preop.configModules.module3.imagePath=../img/clearpixel.gif > preop.configModules.module3.userFriendlyName=Utimacos's CryptoServer > Hardware Security Module > preop.module.token=CBUAETEST > ------------------------------------------- > > Arshad Noor > StrongAuth, Inc. > > Christina Fu wrote: >> Hi Arshad, >> >> Just a thought. Did you try removing the space for your token name? >> >> Christina >> >> Arshad Noor wrote: >>> Can someone from the DogTag team explain the process by which >>> the installation servlet "finds" PKCS11 modules/HSMs and logs >>> into them? Alternatively, if you can point me to the specific >>> source module that performs this, I'd be happy to look at it >>> myself. >>> >>> I'm still baffled by our inability to have the installation >>> servlet find the Utimaco HSM module, despite the fact that >>> modutil sees it: >>> >>> $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list >>> >>> Listing of PKCS #11 Modules >>> ----------------------------------------------------------- >>> 1. NSS Internal PKCS #11 Module >>> slots: 2 slots attached >>> status: loaded >>> >>> slot: NSS Internal Cryptographic Services >>> token: NSS Generic Crypto Services >>> >>> slot: NSS User Private Key and Certificate Services >>> token: NSS Certificate DB >>> >>> 2. CryptoServer >>> library name: /usr/bin/libcs2_pkcs11.so >>> slots: 1 slot attached >>> status: loaded >>> >>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>> token: CBUAE TEST >>> ----------------------------------------------------------- >>> >>> >>> There were some SELinux errors, but I fixed all of them; despite >>> all calls now being successful, the installation servlet will >>> still not see the HSM. >>> >>> Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >> From arshad.noor at strongauth.com Thu Apr 22 21:57:14 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 22 Apr 2010 14:57:14 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0C4AC.2010904@redhat.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> Message-ID: <4BD0C63A.9060400@strongauth.com> So, if I understand you correctly, you want me to: 1) Make sure that the module is configured correctly in the new CA instance's alias/secmod.db file; and 2) Remove all references to the new HSM from CS.cfg, use a default CS.cfg, so that your configuration module code adds it to CS.cfg based on what's configured in secmod.db? Will get back to you in about 15 minutes. Arshad Noor StrongAuth, Inc. Christina Fu wrote: > Arshad, > > I'm curious. The unsupported modules are supposed to be picked up by > the configuration module. That means, you don't need to add those > configModules in the CS.cfg. > Can you try doing that? > If that works, I'd be interested in knowing if the token name with space > contributed to any part of the issue too. > > Chistina > > Arshad Noor wrote: >> Hi Christina, >> >> Good to hear from you again. >> >> I changed the token name and removed the space, but nothing changed, >> unfortunately: >> >> Listing of PKCS #11 Modules >> ----------------------------------------------------------- >> 1. NSS Internal PKCS #11 Module >> slots: 2 slots attached >> status: loaded >> >> slot: NSS Internal Cryptographic Services >> token: NSS Generic Crypto Services >> >> slot: NSS User Private Key and Certificate Services >> token: NSS Certificate DB >> >> 2. CryptoServer >> library name: /usr/bin/libcs2_pkcs11.so >> slots: 1 slot attached >> status: loaded >> >> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >> token: CBUAETEST >> ----------------------------------------------------------- >> >> The debug file for the new CA instance shows: >> >> ------------------------------------------- >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: display() >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >> module NSS Internal PKCS #11 Module >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: supported >> modules count= 4 >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >> config module: NSS Internal PKCS #11 Module >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: module >> found: NSS Internal PKCS #11 Module >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >> nick name=NSS Generic Crypto Services >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >> logged in?false >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is >> present?true >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token NSS >> Generic Crypto Services not to be added >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >> nick name=Internal Key Storage Token >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >> logged in?true >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is >> present?true >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >> module NSS Internal PKCS #11 Module >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >> config module: nfast >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >> module nfast >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >> config module: lunasa >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >> module lunasa >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >> config module: CryptoServer >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >> module CryptoServer >> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel subpanelno =9 >> ------------------------------------------- >> >> The CS.cfg for this instance has the following: >> >> ------------------------------------------- >> preop.configModules.count=4 >> ... >> preop.configModules.module3.commonName=CryptoServer >> preop.configModules.module3.imagePath=../img/clearpixel.gif >> preop.configModules.module3.userFriendlyName=Utimacos's CryptoServer >> Hardware Security Module >> preop.module.token=CBUAETEST >> ------------------------------------------- >> >> Arshad Noor >> StrongAuth, Inc. >> >> Christina Fu wrote: >>> Hi Arshad, >>> >>> Just a thought. Did you try removing the space for your token name? >>> >>> Christina >>> >>> Arshad Noor wrote: >>>> Can someone from the DogTag team explain the process by which >>>> the installation servlet "finds" PKCS11 modules/HSMs and logs >>>> into them? Alternatively, if you can point me to the specific >>>> source module that performs this, I'd be happy to look at it >>>> myself. >>>> >>>> I'm still baffled by our inability to have the installation >>>> servlet find the Utimaco HSM module, despite the fact that >>>> modutil sees it: >>>> >>>> $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list >>>> >>>> Listing of PKCS #11 Modules >>>> ----------------------------------------------------------- >>>> 1. NSS Internal PKCS #11 Module >>>> slots: 2 slots attached >>>> status: loaded >>>> >>>> slot: NSS Internal Cryptographic Services >>>> token: NSS Generic Crypto Services >>>> >>>> slot: NSS User Private Key and Certificate Services >>>> token: NSS Certificate DB >>>> >>>> 2. CryptoServer >>>> library name: /usr/bin/libcs2_pkcs11.so >>>> slots: 1 slot attached >>>> status: loaded >>>> >>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>> token: CBUAE TEST >>>> ----------------------------------------------------------- >>>> >>>> >>>> There were some SELinux errors, but I fixed all of them; despite >>>> all calls now being successful, the installation servlet will >>>> still not see the HSM. >>>> >>>> Thanks. >>>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >>> > From arshad.noor at strongauth.com Thu Apr 22 22:43:03 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 22 Apr 2010 15:43:03 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0C63A.9060400@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> Message-ID: <4BD0D0F7.7080305@strongauth.com> I'm afraid it didn't pick up the new module, Christina. modutil shows it correctly, but as you can see from the attached PNG, the servlet did not find the HSM. Based on Michael StJohn's postings and some feedback I have from the vendor, it appears that the 32-bit version of DogTag may be working; but we're testing on a 64-bit version of Fedora 11 and DogTag. Could that be causing the problem? The PKCS11 library from the HSM vendor is 64-bit. Arshad Noor StrongAuth, Inc. Arshad Noor wrote: > So, if I understand you correctly, you want me to: > > 1) Make sure that the module is configured correctly in the > new CA instance's alias/secmod.db file; and > > 2) Remove all references to the new HSM from CS.cfg, use a > default CS.cfg, so that your configuration module code > adds it to CS.cfg based on what's configured in secmod.db? > > Will get back to you in about 15 minutes. > > Arshad Noor > StrongAuth, Inc. > > Christina Fu wrote: >> Arshad, >> >> I'm curious. The unsupported modules are supposed to be picked up by >> the configuration module. That means, you don't need to add those >> configModules in the CS.cfg. >> Can you try doing that? >> If that works, I'd be interested in knowing if the token name with >> space contributed to any part of the issue too. >> >> Chistina >> >> Arshad Noor wrote: >>> Hi Christina, >>> >>> Good to hear from you again. >>> >>> I changed the token name and removed the space, but nothing changed, >>> unfortunately: >>> >>> Listing of PKCS #11 Modules >>> ----------------------------------------------------------- >>> 1. NSS Internal PKCS #11 Module >>> slots: 2 slots attached >>> status: loaded >>> >>> slot: NSS Internal Cryptographic Services >>> token: NSS Generic Crypto Services >>> >>> slot: NSS User Private Key and Certificate Services >>> token: NSS Certificate DB >>> >>> 2. CryptoServer >>> library name: /usr/bin/libcs2_pkcs11.so >>> slots: 1 slot attached >>> status: loaded >>> >>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>> token: CBUAETEST >>> ----------------------------------------------------------- >>> >>> The debug file for the new CA instance shows: >>> >>> ------------------------------------------- >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: display() >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>> module NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: >>> supported modules count= 4 >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >>> config module: NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: module >>> found: NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> nick name=NSS Generic Crypto Services >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> logged in?false >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is >>> present?true >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> NSS Generic Crypto Services not to be added >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> nick name=Internal Key Storage Token >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>> logged in?true >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token is >>> present?true >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module NSS Internal PKCS #11 Module >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >>> config module: nfast >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module nfast >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >>> config module: lunasa >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module lunasa >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got from >>> config module: CryptoServer >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>> module CryptoServer >>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel >>> subpanelno =9 >>> ------------------------------------------- >>> >>> The CS.cfg for this instance has the following: >>> >>> ------------------------------------------- >>> preop.configModules.count=4 >>> ... >>> preop.configModules.module3.commonName=CryptoServer >>> preop.configModules.module3.imagePath=../img/clearpixel.gif >>> preop.configModules.module3.userFriendlyName=Utimacos's CryptoServer >>> Hardware Security Module >>> preop.module.token=CBUAETEST >>> ------------------------------------------- >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> Christina Fu wrote: >>>> Hi Arshad, >>>> >>>> Just a thought. Did you try removing the space for your token name? >>>> >>>> Christina >>>> >>>> Arshad Noor wrote: >>>>> Can someone from the DogTag team explain the process by which >>>>> the installation servlet "finds" PKCS11 modules/HSMs and logs >>>>> into them? Alternatively, if you can point me to the specific >>>>> source module that performs this, I'd be happy to look at it >>>>> myself. >>>>> >>>>> I'm still baffled by our inability to have the installation >>>>> servlet find the Utimaco HSM module, despite the fact that >>>>> modutil sees it: >>>>> >>>>> $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list >>>>> >>>>> Listing of PKCS #11 Modules >>>>> ----------------------------------------------------------- >>>>> 1. NSS Internal PKCS #11 Module >>>>> slots: 2 slots attached >>>>> status: loaded >>>>> >>>>> slot: NSS Internal Cryptographic Services >>>>> token: NSS Generic Crypto Services >>>>> >>>>> slot: NSS User Private Key and Certificate Services >>>>> token: NSS Certificate DB >>>>> >>>>> 2. CryptoServer >>>>> library name: /usr/bin/libcs2_pkcs11.so >>>>> slots: 1 slot attached >>>>> status: loaded >>>>> >>>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>>> token: CBUAE TEST >>>>> ----------------------------------------------------------- >>>>> >>>>> >>>>> There were some SELinux errors, but I fixed all of them; despite >>>>> all calls now being successful, the installation servlet will >>>>> still not see the HSM. >>>>> >>>>> Thanks. >>>>> >>>>> Arshad Noor >>>>> StrongAuth, Inc. >>>>> >>>>> _______________________________________________ >>>>> Pki-users mailing list >>>>> Pki-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> >> > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From ckannan at redhat.com Thu Apr 22 23:38:12 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Thu, 22 Apr 2010 16:38:12 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0D0F7.7080305@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> Message-ID: <4BD0DDE4.50600@redhat.com> On 04/22/2010 03:43 PM, Arshad Noor wrote: > I'm afraid it didn't pick up the new module, Christina. modutil > shows it correctly, but as you can see from the attached PNG, the > servlet did not find the HSM. Looks like the NSS layer has no problems identifying the token. can you use this tool and see if the JSS layer can see it as well ? http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html > > Based on Michael StJohn's postings and some feedback I have from > the vendor, it appears that the 32-bit version of DogTag may be > working; but we're testing on a 64-bit version of Fedora 11 and > DogTag. Could that be causing the problem? The PKCS11 library > from the HSM vendor is 64-bit. > > Arshad Noor > StrongAuth, Inc. > > Arshad Noor wrote: >> So, if I understand you correctly, you want me to: >> >> 1) Make sure that the module is configured correctly in the >> new CA instance's alias/secmod.db file; and >> >> 2) Remove all references to the new HSM from CS.cfg, use a >> default CS.cfg, so that your configuration module code >> adds it to CS.cfg based on what's configured in secmod.db? >> >> Will get back to you in about 15 minutes. >> >> Arshad Noor >> StrongAuth, Inc. >> >> Christina Fu wrote: >>> Arshad, >>> >>> I'm curious. The unsupported modules are supposed to be picked up >>> by the configuration module. That means, you don't need to add >>> those configModules in the CS.cfg. >>> Can you try doing that? >>> If that works, I'd be interested in knowing if the token name with >>> space contributed to any part of the issue too. >>> >>> Chistina >>> >>> Arshad Noor wrote: >>>> Hi Christina, >>>> >>>> Good to hear from you again. >>>> >>>> I changed the token name and removed the space, but nothing changed, >>>> unfortunately: >>>> >>>> Listing of PKCS #11 Modules >>>> ----------------------------------------------------------- >>>> 1. NSS Internal PKCS #11 Module >>>> slots: 2 slots attached >>>> status: loaded >>>> >>>> slot: NSS Internal Cryptographic Services >>>> token: NSS Generic Crypto Services >>>> >>>> slot: NSS User Private Key and Certificate Services >>>> token: NSS Certificate DB >>>> >>>> 2. CryptoServer >>>> library name: /usr/bin/libcs2_pkcs11.so >>>> slots: 1 slot attached >>>> status: loaded >>>> >>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>> token: CBUAETEST >>>> ----------------------------------------------------------- >>>> >>>> The debug file for the new CA instance shows: >>>> >>>> ------------------------------------------- >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: display() >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>>> module NSS Internal PKCS #11 Module >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: >>>> supported modules count= 4 >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>>> from config module: NSS Internal PKCS #11 Module >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: module >>>> found: NSS Internal PKCS #11 Module >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>>> nick name=NSS Generic Crypto Services >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>>> logged in?false >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>>> is present?true >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>>> NSS Generic Crypto Services not to be added >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>>> nick name=Internal Key Storage Token >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>>> logged in?true >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: token >>>> is present?true >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>>> module NSS Internal PKCS #11 Module >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>>> from config module: nfast >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>>> module nfast >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>>> from config module: lunasa >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>>> module lunasa >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: got >>>> from config module: CryptoServer >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel: adding >>>> module CryptoServer >>>> [22/Apr/2010:13:59:43][http-11004-Processor21]: ModulePanel >>>> subpanelno =9 >>>> ------------------------------------------- >>>> >>>> The CS.cfg for this instance has the following: >>>> >>>> ------------------------------------------- >>>> preop.configModules.count=4 >>>> ... >>>> preop.configModules.module3.commonName=CryptoServer >>>> preop.configModules.module3.imagePath=../img/clearpixel.gif >>>> preop.configModules.module3.userFriendlyName=Utimacos's >>>> CryptoServer Hardware Security Module >>>> preop.module.token=CBUAETEST >>>> ------------------------------------------- >>>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> Christina Fu wrote: >>>>> Hi Arshad, >>>>> >>>>> Just a thought. Did you try removing the space for your token name? >>>>> >>>>> Christina >>>>> >>>>> Arshad Noor wrote: >>>>>> Can someone from the DogTag team explain the process by which >>>>>> the installation servlet "finds" PKCS11 modules/HSMs and logs >>>>>> into them? Alternatively, if you can point me to the specific >>>>>> source module that performs this, I'd be happy to look at it >>>>>> myself. >>>>>> >>>>>> I'm still baffled by our inability to have the installation >>>>>> servlet find the Utimaco HSM module, despite the fact that >>>>>> modutil sees it: >>>>>> >>>>>> $ pet105:~> modutil -dbdir /var/lib/subca01/alias -nocertdb -list >>>>>> >>>>>> Listing of PKCS #11 Modules >>>>>> ----------------------------------------------------------- >>>>>> 1. NSS Internal PKCS #11 Module >>>>>> slots: 2 slots attached >>>>>> status: loaded >>>>>> >>>>>> slot: NSS Internal Cryptographic Services >>>>>> token: NSS Generic Crypto Services >>>>>> >>>>>> slot: NSS User Private Key and Certificate Services >>>>>> token: NSS Certificate DB >>>>>> >>>>>> 2. CryptoServer >>>>>> library name: /usr/bin/libcs2_pkcs11.so >>>>>> slots: 1 slot attached >>>>>> status: loaded >>>>>> >>>>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>>>> token: CBUAE TEST >>>>>> ----------------------------------------------------------- >>>>>> >>>>>> >>>>>> There were some SELinux errors, but I fixed all of them; despite >>>>>> all calls now being successful, the installation servlet will >>>>>> still not see the HSM. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Arshad Noor >>>>>> StrongAuth, Inc. >>>>>> >>>>>> _______________________________________________ >>>>>> Pki-users mailing list >>>>>> Pki-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>>> >>> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Thu Apr 22 23:44:12 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 22 Apr 2010 16:44:12 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0DDE4.50600@redhat.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> Message-ID: <4BD0DF4C.8010708@strongauth.com> Interesting; it did not: # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. CryptoServer library name: /usr/bin/libcs2_pkcs11.so slots: 1 slot attached status: loaded slot: CryptoServer Device '/dev/cs2' - Slot No: 0 token: CBUAETEST ----------------------------------------------------------- # pet105:~> TokenInfo /var/lib/subca01/alias Database Path: /var/lib/subca01/alias Found external module 'NSS Internal PKCS #11 Module' # pet105:~> And there were no SELinux errors in the audit log. Arshad Noor StrongAuth, Inc. Chandrasekar Kannan wrote: > > Looks like the NSS layer has no problems identifying the token. > can you use this tool and see if the JSS layer can see it as well ? > > http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html > From ckannan at redhat.com Thu Apr 22 23:52:52 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Thu, 22 Apr 2010 16:52:52 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0DF4C.8010708@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> Message-ID: <4BD0E154.20304@redhat.com> On 04/22/2010 04:44 PM, Arshad Noor wrote: > Interesting; it did not: > > # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. CryptoServer > library name: /usr/bin/libcs2_pkcs11.so > slots: 1 slot attached > status: loaded > > slot: CryptoServer Device '/dev/cs2' - Slot No: 0 > token: CBUAETEST > ----------------------------------------------------------- > # pet105:~> TokenInfo /var/lib/subca01/alias > Database Path: /var/lib/subca01/alias > Found external module 'NSS Internal PKCS #11 Module' > # pet105:~> > > And there were no SELinux errors in the audit log. Can you 'setenforce 0' (putting selinux to permissive mode ) and try one more time ?. > > Arshad Noor > StrongAuth, Inc. > > > Chandrasekar Kannan wrote: >> >> Looks like the NSS layer has no problems identifying the token. >> can you use this tool and see if the JSS layer can see it as well ? >> >> http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html >> >> From arshad.noor at strongauth.com Thu Apr 22 23:56:44 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Thu, 22 Apr 2010 16:56:44 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0E154.20304@redhat.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> Message-ID: <4BD0E23C.3070608@strongauth.com> No luck. ------------- # pet105:~> setenforce 0 # pet105:~> TokenInfo /var/lib/subca01/alias Database Path: /var/lib/subca01/alias Found external module 'NSS Internal PKCS #11 Module' # pet105:~> ------------- Output from audit.log: ------------- type=MAC_STATUS msg=audit(1271980444.565:345): enforcing=0 old_enforcing=1 auid=500 ses=5 type=SYSCALL msg=audit(1271980444.565:345): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fff300dfb20 a2=1 a3=fffffff8 items=0 ppid=32217 pid=32292 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=5 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) ------------- Arshad Noor StrongAuth, Inc. Chandrasekar Kannan wrote: > On 04/22/2010 04:44 PM, Arshad Noor wrote: >> Interesting; it did not: >> >> # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list >> >> Listing of PKCS #11 Modules >> ----------------------------------------------------------- >> 1. NSS Internal PKCS #11 Module >> slots: 2 slots attached >> status: loaded >> >> slot: NSS Internal Cryptographic Services >> token: NSS Generic Crypto Services >> >> slot: NSS User Private Key and Certificate Services >> token: NSS Certificate DB >> >> 2. CryptoServer >> library name: /usr/bin/libcs2_pkcs11.so >> slots: 1 slot attached >> status: loaded >> >> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >> token: CBUAETEST >> ----------------------------------------------------------- >> # pet105:~> TokenInfo /var/lib/subca01/alias >> Database Path: /var/lib/subca01/alias >> Found external module 'NSS Internal PKCS #11 Module' >> # pet105:~> >> >> And there were no SELinux errors in the audit log. > > Can you 'setenforce 0' (putting selinux to permissive mode ) > and try one more time ?. > > >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> Chandrasekar Kannan wrote: >>> >>> Looks like the NSS layer has no problems identifying the token. >>> can you use this tool and see if the JSS layer can see it as well ? >>> >>> http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html >>> >>> > From arshad.noor at strongauth.com Mon Apr 26 16:51:07 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Mon, 26 Apr 2010 09:51:07 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD0E23C.3070608@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> Message-ID: <4BD5C47B.5010605@strongauth.com> Do you have any update on the JSS issue, Chandrasekar? Thanks. Arshad Noor StrongAuth, Inc. Arshad Noor wrote: > No luck. > > ------------- > # pet105:~> setenforce 0 > # pet105:~> TokenInfo /var/lib/subca01/alias > Database Path: /var/lib/subca01/alias > Found external module 'NSS Internal PKCS #11 Module' > # pet105:~> > ------------- > > Output from audit.log: > > ------------- > type=MAC_STATUS msg=audit(1271980444.565:345): enforcing=0 > old_enforcing=1 auid=500 ses=5 > type=SYSCALL msg=audit(1271980444.565:345): arch=c000003e syscall=1 > success=yes exit=1 a0=3 a1=7fff300dfb20 a2=1 a3=fffffff8 items=0 > ppid=32217 pid=32292 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts4 ses=5 comm="setenforce" > exe="/usr/sbin/setenforce" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > ------------- > > Arshad Noor > StrongAuth, Inc. > > Chandrasekar Kannan wrote: >> On 04/22/2010 04:44 PM, Arshad Noor wrote: >>> Interesting; it did not: >>> >>> # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list >>> >>> Listing of PKCS #11 Modules >>> ----------------------------------------------------------- >>> 1. NSS Internal PKCS #11 Module >>> slots: 2 slots attached >>> status: loaded >>> >>> slot: NSS Internal Cryptographic Services >>> token: NSS Generic Crypto Services >>> >>> slot: NSS User Private Key and Certificate Services >>> token: NSS Certificate DB >>> >>> 2. CryptoServer >>> library name: /usr/bin/libcs2_pkcs11.so >>> slots: 1 slot attached >>> status: loaded >>> >>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>> token: CBUAETEST >>> ----------------------------------------------------------- >>> # pet105:~> TokenInfo /var/lib/subca01/alias >>> Database Path: /var/lib/subca01/alias >>> Found external module 'NSS Internal PKCS #11 Module' >>> # pet105:~> >>> >>> And there were no SELinux errors in the audit log. >> >> Can you 'setenforce 0' (putting selinux to permissive mode ) >> and try one more time ?. >> >> >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> >>> Chandrasekar Kannan wrote: >>>> >>>> Looks like the NSS layer has no problems identifying the token. >>>> can you use this tool and see if the JSS layer can see it as well ? >>>> >>>> http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html >>>> >>>> >> > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From ckannan at redhat.com Mon Apr 26 16:53:18 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Mon, 26 Apr 2010 09:53:18 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD5C47B.5010605@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> Message-ID: <4BD5C4FE.6030902@redhat.com> On 04/26/2010 09:51 AM, Arshad Noor wrote: > Do you have any update on the JSS issue, Chandrasekar? Thanks. I don't. We may need to debug the JSS code to figure out what the problem is.... > > Arshad Noor > StrongAuth, Inc. > > Arshad Noor wrote: >> No luck. >> >> ------------- >> # pet105:~> setenforce 0 >> # pet105:~> TokenInfo /var/lib/subca01/alias >> Database Path: /var/lib/subca01/alias >> Found external module 'NSS Internal PKCS #11 Module' >> # pet105:~> >> ------------- >> >> Output from audit.log: >> >> ------------- >> type=MAC_STATUS msg=audit(1271980444.565:345): enforcing=0 >> old_enforcing=1 auid=500 ses=5 >> type=SYSCALL msg=audit(1271980444.565:345): arch=c000003e syscall=1 >> success=yes exit=1 a0=3 a1=7fff300dfb20 a2=1 a3=fffffff8 items=0 >> ppid=32217 pid=32292 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 >> egid=0 sgid=0 fsgid=0 tty=pts4 ses=5 comm="setenforce" >> exe="/usr/sbin/setenforce" >> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) >> ------------- >> >> Arshad Noor >> StrongAuth, Inc. >> >> Chandrasekar Kannan wrote: >>> On 04/22/2010 04:44 PM, Arshad Noor wrote: >>>> Interesting; it did not: >>>> >>>> # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list >>>> >>>> Listing of PKCS #11 Modules >>>> ----------------------------------------------------------- >>>> 1. NSS Internal PKCS #11 Module >>>> slots: 2 slots attached >>>> status: loaded >>>> >>>> slot: NSS Internal Cryptographic Services >>>> token: NSS Generic Crypto Services >>>> >>>> slot: NSS User Private Key and Certificate Services >>>> token: NSS Certificate DB >>>> >>>> 2. CryptoServer >>>> library name: /usr/bin/libcs2_pkcs11.so >>>> slots: 1 slot attached >>>> status: loaded >>>> >>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>> token: CBUAETEST >>>> ----------------------------------------------------------- >>>> # pet105:~> TokenInfo /var/lib/subca01/alias >>>> Database Path: /var/lib/subca01/alias >>>> Found external module 'NSS Internal PKCS #11 Module' >>>> # pet105:~> >>>> >>>> And there were no SELinux errors in the audit log. >>> >>> Can you 'setenforce 0' (putting selinux to permissive mode ) >>> and try one more time ?. >>> >>> >>>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> >>>> Chandrasekar Kannan wrote: >>>>> >>>>> Looks like the NSS layer has no problems identifying the token. >>>>> can you use this tool and see if the JSS layer can see it as well ? >>>>> >>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html >>>>> >>>>> >>> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users From cfu at redhat.com Tue Apr 27 02:46:25 2010 From: cfu at redhat.com (Christina Fu) Date: Mon, 26 Apr 2010 19:46:25 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD5C4FE.6030902@redhat.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> Message-ID: <4BD65001.3070102@redhat.com> Chandrasekar Kannan wrote: > On 04/26/2010 09:51 AM, Arshad Noor wrote: >> Do you have any update on the JSS issue, Chandrasekar? Thanks. > > I don't. We may need to debug the JSS code to figure out > what the problem is.... > > >> >> Arshad Noor >> StrongAuth, Inc. >> >> Arshad Noor wrote: >>> No luck. >>> >>> ------------- >>> # pet105:~> setenforce 0 >>> # pet105:~> TokenInfo /var/lib/subca01/alias >>> Database Path: /var/lib/subca01/alias >>> Found external module 'NSS Internal PKCS #11 Module' >>> # pet105:~> >>> ------------- >>> >>> Output from audit.log: >>> >>> ------------- >>> type=MAC_STATUS msg=audit(1271980444.565:345): enforcing=0 >>> old_enforcing=1 auid=500 ses=5 >>> type=SYSCALL msg=audit(1271980444.565:345): arch=c000003e syscall=1 >>> success=yes exit=1 a0=3 a1=7fff300dfb20 a2=1 a3=fffffff8 items=0 >>> ppid=32217 pid=32292 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 >>> egid=0 sgid=0 fsgid=0 tty=pts4 ses=5 comm="setenforce" >>> exe="/usr/sbin/setenforce" >>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) >>> ------------- >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> Chandrasekar Kannan wrote: >>>> On 04/22/2010 04:44 PM, Arshad Noor wrote: >>>>> Interesting; it did not: >>>>> >>>>> # pet105:~> modutil -dbdir /var/lib/subca01/alias/ -nocertdb -list >>>>> >>>>> Listing of PKCS #11 Modules >>>>> ----------------------------------------------------------- >>>>> 1. NSS Internal PKCS #11 Module >>>>> slots: 2 slots attached >>>>> status: loaded >>>>> >>>>> slot: NSS Internal Cryptographic Services >>>>> token: NSS Generic Crypto Services >>>>> >>>>> slot: NSS User Private Key and Certificate Services >>>>> token: NSS Certificate DB >>>>> >>>>> 2. CryptoServer >>>>> library name: /usr/bin/libcs2_pkcs11.so >>>>> slots: 1 slot attached >>>>> status: loaded >>>>> >>>>> slot: CryptoServer Device '/dev/cs2' - Slot No: 0 >>>>> token: CBUAETEST >>>>> ----------------------------------------------------------- >>>>> # pet105:~> TokenInfo /var/lib/subca01/alias >>>>> Database Path: /var/lib/subca01/alias >>>>> Found external module 'NSS Internal PKCS #11 Module' >>>>> # pet105:~> >>>>> >>>>> And there were no SELinux errors in the audit log. >>>> >>>> Can you 'setenforce 0' (putting selinux to permissive mode ) >>>> and try one more time ?. >>>> >>>> >>>>> >>>>> Arshad Noor >>>>> StrongAuth, Inc. >>>>> >>>>> >>>>> Chandrasekar Kannan wrote: >>>>>> >>>>>> Looks like the NSS layer has no problems identifying the token. >>>>>> can you use this tool and see if the JSS layer can see it as well ? >>>>>> >>>>>> http://www.redhat.com/docs/manuals/cert-system/8.0/cli/html/TokenInfo.html >>>>>> >>>>>> >>>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users Actually, I did spend some time looking into JSS code. The result was inconclusive. The code appeared to be reasonable. I do suspect, however, without looking closely at the code, that somehow the module is unloaded somewhere along the way. I'm curious whether this is an issue on this particular HSM, or if it's a matter of handling external modules (including software modules) in general. Has anyone had any success installing/using certicom module on this platform, for example? Again, I did not see any email from another member (StJohns?) that you mentioned claiming success with Utimaco HSM on a 32 bit machine... could you please forward the email? Another thing is, I'm not familiar with Utimaco HSM, but you might want to find out how to turn on debugger. Otherwise, try turning on NSS debugging, which might give you some clue. Christina From msj at nthpermutation.com Wed Apr 28 00:40:40 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Tue, 27 Apr 2010 20:40:40 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD65001.3070102@redhat.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> Message-ID: <4BD78408.9050105@nthpermutation.com> On 4/26/2010 10:46 PM, Christina Fu wrote: > Actually, I did spend some time looking into JSS code. The result was > inconclusive. The code appeared to be reasonable. I do suspect, > however, without looking closely at the code, that somehow the module > is unloaded somewhere along the way. > I'm curious whether this is an issue on this particular HSM, or if > it's a matter of handling external modules (including software > modules) in general. > Has anyone had any success installing/using certicom module on this > platform, for example? > > Again, I did not see any email from another member (StJohns?) that you > mentioned claiming success with Utimaco HSM on a 32 bit machine... > could you please forward the email? > Another thing is, I'm not familiar with Utimaco HSM, but you might > want to find out how to turn on debugger. > > Otherwise, try turning on NSS debugging, which might give you some clue. > > Christina > Hi Christina - I had to put work on this aside for a few days, but am getting back to it. I've had uneven results. The time that I got the HSM to show up with the slots, but I didn't get the "Login" button. This time, I didn't even get the HSM to show up. The first time, I added the HSM manually, the second via a mod to the create script. Still working my way through it. I modified pki_create_instance to add both the Utimaco library and the Coolkey PKCS11 libary. I had to turn off SELinux enforcement to get Coolkey to show up on the list, but even then, the Utimaco lib didn't. I haven't had a chance to go back and check again. Mike From arshad.noor at strongauth.com Wed Apr 28 00:51:13 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 27 Apr 2010 17:51:13 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD78408.9050105@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> Message-ID: <4BD78681.90602@strongauth.com> Was this on a 32-bit or 64-bit environment, Mike? I was planning to test this with the 32-bit version of Fedora 11, based on your assertion that it worked. But, now it appears that this might be unpredictable. Is that right? Arshad Noor StrongAuth, Inc. Michael StJohns wrote: > On 4/26/2010 10:46 PM, Christina Fu wrote: >> Actually, I did spend some time looking into JSS code. The result was >> inconclusive. The code appeared to be reasonable. I do suspect, >> however, without looking closely at the code, that somehow the module >> is unloaded somewhere along the way. >> I'm curious whether this is an issue on this particular HSM, or if >> it's a matter of handling external modules (including software >> modules) in general. >> Has anyone had any success installing/using certicom module on this >> platform, for example? >> >> Again, I did not see any email from another member (StJohns?) that you >> mentioned claiming success with Utimaco HSM on a 32 bit machine... >> could you please forward the email? >> Another thing is, I'm not familiar with Utimaco HSM, but you might >> want to find out how to turn on debugger. >> >> Otherwise, try turning on NSS debugging, which might give you some clue. >> >> Christina >> > > Hi Christina - > > I had to put work on this aside for a few days, but am getting back to > it. I've had uneven results. The time that I got the HSM to show up > with the slots, but I didn't get the "Login" button. This time, I > didn't even get the HSM to show up. The first time, I added the HSM > manually, the second via a mod to the create script. Still working my > way through it. > > I modified pki_create_instance to add both the Utimaco library and the > Coolkey PKCS11 libary. I had to turn off SELinux enforcement to get > Coolkey to show up on the list, but even then, the Utimaco lib didn't. > I haven't had a chance to go back and check again. > > Mike > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From mmercier at gmail.com Wed Apr 28 00:53:33 2010 From: mmercier at gmail.com (Mike Mercier) Date: Tue, 27 Apr 2010 20:53:33 -0400 Subject: [Pki-users] Reset pkiconsole "administrator" password? Message-ID: Hello, Is there a way to reset the pkiconsole "administrator" (I think the username is actually 'admin') password? Can someone point me to the documentation? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From msj at nthpermutation.com Wed Apr 28 01:51:43 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Tue, 27 Apr 2010 21:51:43 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD78681.90602@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> Message-ID: <4BD794AF.3030401@nthpermutation.com> OK - Using my recompiled/relinked version of the Utimaco library on Fedora 12 - 32 bit. I can consistently get the Utimaco library to show up in the list with the three slots I've initialized. BUT - none of those show up with the "Login" button. The reason I couldn't get it to work before was because of the coolkey library... if that libary is loaded (name "coolkey"), modutil and TokenInfo both see it, but only the coolkey library gets listed on the setup page. I deleted the coolkey library, restarted the server and the Utimaco slots showed up. I re-added the coolkey library with the name "zcoolkey", restarted the server - only the Utimaco slots showed up. - At this point I got suspicious and tried one more thing. I deleted the Utimaco library with the name "utimaco", restarted the server. The zcoolkey library showed up. Hmm..... looks like for some reason, only the first module (alphabetically) is being listed/loaded. Mike On 4/27/2010 8:51 PM, Arshad Noor wrote: > Was this on a 32-bit or 64-bit environment, Mike? I was planning to > test this with the 32-bit version of Fedora 11, based on your assertion > that it worked. But, now it appears that this might be unpredictable. > Is that right? > > Arshad Noor > StrongAuth, Inc. > > Michael StJohns wrote: >> On 4/26/2010 10:46 PM, Christina Fu wrote: >>> Actually, I did spend some time looking into JSS code. The result >>> was inconclusive. The code appeared to be reasonable. I do >>> suspect, however, without looking closely at the code, that somehow >>> the module is unloaded somewhere along the way. >>> I'm curious whether this is an issue on this particular HSM, or if >>> it's a matter of handling external modules (including software >>> modules) in general. >>> Has anyone had any success installing/using certicom module on this >>> platform, for example? >>> >>> Again, I did not see any email from another member (StJohns?) that >>> you mentioned claiming success with Utimaco HSM on a 32 bit >>> machine... could you please forward the email? >>> Another thing is, I'm not familiar with Utimaco HSM, but you might >>> want to find out how to turn on debugger. >>> >>> Otherwise, try turning on NSS debugging, which might give you some >>> clue. >>> >>> Christina >>> >> >> Hi Christina - >> >> I had to put work on this aside for a few days, but am getting back >> to it. I've had uneven results. The time that I got the HSM to show >> up with the slots, but I didn't get the "Login" button. This time, I >> didn't even get the HSM to show up. The first time, I added the HSM >> manually, the second via a mod to the create script. Still working >> my way through it. >> >> I modified pki_create_instance to add both the Utimaco library and >> the Coolkey PKCS11 libary. I had to turn off SELinux enforcement to >> get Coolkey to show up on the list, but even then, the Utimaco lib >> didn't. I haven't had a chance to go back and check again. >> >> Mike >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users From arshad.noor at strongauth.com Wed Apr 28 01:59:01 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 27 Apr 2010 18:59:01 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD794AF.3030401@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> <4BD794AF.3030401@nthpermutation.com> Message-ID: <4BD79665.2040202@strongauth.com> When the Utimaco slots show up, do they consistently show up with a Login button? If there is no Login button, what would be the point of displaying the slot? One wouldn't be able to use it to generate keys. Arshad Noor StrongAuth, Inc. Michael StJohns wrote: > OK - > > Using my recompiled/relinked version of the Utimaco library on Fedora 12 > - 32 bit. > > I can consistently get the Utimaco library to show up in the list with > the three slots I've initialized. BUT - none of those show up with the > "Login" button. > > The reason I couldn't get it to work before was because of the coolkey > library... if that libary is loaded (name "coolkey"), modutil and > TokenInfo both see it, but only the coolkey library gets listed on the > setup page. > > I deleted the coolkey library, restarted the server and the Utimaco > slots showed up. > > I re-added the coolkey library with the name "zcoolkey", restarted the > server - only the Utimaco slots showed up. > > - At this point I got suspicious and tried one more thing. > > I deleted the Utimaco library with the name "utimaco", restarted the > server. The zcoolkey library showed up. > > Hmm..... looks like for some reason, only the first module > (alphabetically) is being listed/loaded. > > Mike > > > > > > On 4/27/2010 8:51 PM, Arshad Noor wrote: >> Was this on a 32-bit or 64-bit environment, Mike? I was planning to >> test this with the 32-bit version of Fedora 11, based on your assertion >> that it worked. But, now it appears that this might be unpredictable. >> Is that right? >> >> Arshad Noor >> StrongAuth, Inc. >> >> Michael StJohns wrote: >>> On 4/26/2010 10:46 PM, Christina Fu wrote: >>>> Actually, I did spend some time looking into JSS code. The result >>>> was inconclusive. The code appeared to be reasonable. I do >>>> suspect, however, without looking closely at the code, that somehow >>>> the module is unloaded somewhere along the way. >>>> I'm curious whether this is an issue on this particular HSM, or if >>>> it's a matter of handling external modules (including software >>>> modules) in general. >>>> Has anyone had any success installing/using certicom module on this >>>> platform, for example? >>>> >>>> Again, I did not see any email from another member (StJohns?) that >>>> you mentioned claiming success with Utimaco HSM on a 32 bit >>>> machine... could you please forward the email? >>>> Another thing is, I'm not familiar with Utimaco HSM, but you might >>>> want to find out how to turn on debugger. >>>> >>>> Otherwise, try turning on NSS debugging, which might give you some >>>> clue. >>>> >>>> Christina >>>> >>> >>> Hi Christina - >>> >>> I had to put work on this aside for a few days, but am getting back >>> to it. I've had uneven results. The time that I got the HSM to show >>> up with the slots, but I didn't get the "Login" button. This time, I >>> didn't even get the HSM to show up. The first time, I added the HSM >>> manually, the second via a mod to the create script. Still working >>> my way through it. >>> >>> I modified pki_create_instance to add both the Utimaco library and >>> the Coolkey PKCS11 libary. I had to turn off SELinux enforcement to >>> get Coolkey to show up on the list, but even then, the Utimaco lib >>> didn't. I haven't had a chance to go back and check again. >>> >>> Mike >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users > From msj at nthpermutation.com Wed Apr 28 02:11:44 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Tue, 27 Apr 2010 22:11:44 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD794AF.3030401@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> <4BD794AF.3030401@nthpermutation.com> Message-ID: <4BD79960.3060400@nthpermutation.com> Interesting. I added the Utimaco to the list of supported modules (CS.cfg - preop.configModules). This time it showed up in the list in the supported section along with the "Login" tag. I clicked "Login" and manually logged in, selected the module as the default, and completed the enrollment. I then went back to the HSM and using the Utimaco provided tool confirmed all the keys etc are present. zcoolkey showed up in the unsupported list. So try: Add utimaco to the pkicreate script in /usr/bin Add utimaco to the supported list in the default CS.cfg /usr/share/pki/ca/conf Mike On 4/27/2010 9:51 PM, Michael StJohns wrote: > OK - > > Using my recompiled/relinked version of the Utimaco library on Fedora > 12 - 32 bit. > > I can consistently get the Utimaco library to show up in the list with > the three slots I've initialized. BUT - none of those show up with > the "Login" button. > > The reason I couldn't get it to work before was because of the coolkey > library... if that libary is loaded (name "coolkey"), modutil and > TokenInfo both see it, but only the coolkey library gets listed on the > setup page. > > I deleted the coolkey library, restarted the server and the Utimaco > slots showed up. > > I re-added the coolkey library with the name "zcoolkey", restarted the > server - only the Utimaco slots showed up. > > - At this point I got suspicious and tried one more thing. > > I deleted the Utimaco library with the name "utimaco", restarted the > server. The zcoolkey library showed up. > > Hmm..... looks like for some reason, only the first module > (alphabetically) is being listed/loaded. > > Mike > > > > > > On 4/27/2010 8:51 PM, Arshad Noor wrote: >> Was this on a 32-bit or 64-bit environment, Mike? I was planning to >> test this with the 32-bit version of Fedora 11, based on your assertion >> that it worked. But, now it appears that this might be unpredictable. >> Is that right? >> >> Arshad Noor >> StrongAuth, Inc. >> >> Michael StJohns wrote: >>> On 4/26/2010 10:46 PM, Christina Fu wrote: >>>> Actually, I did spend some time looking into JSS code. The result >>>> was inconclusive. The code appeared to be reasonable. I do >>>> suspect, however, without looking closely at the code, that somehow >>>> the module is unloaded somewhere along the way. >>>> I'm curious whether this is an issue on this particular HSM, or if >>>> it's a matter of handling external modules (including software >>>> modules) in general. >>>> Has anyone had any success installing/using certicom module on this >>>> platform, for example? >>>> >>>> Again, I did not see any email from another member (StJohns?) that >>>> you mentioned claiming success with Utimaco HSM on a 32 bit >>>> machine... could you please forward the email? >>>> Another thing is, I'm not familiar with Utimaco HSM, but you might >>>> want to find out how to turn on debugger. >>>> >>>> Otherwise, try turning on NSS debugging, which might give you some >>>> clue. >>>> >>>> Christina >>>> >>> >>> Hi Christina - >>> >>> I had to put work on this aside for a few days, but am getting back >>> to it. I've had uneven results. The time that I got the HSM to >>> show up with the slots, but I didn't get the "Login" button. This >>> time, I didn't even get the HSM to show up. The first time, I added >>> the HSM manually, the second via a mod to the create script. Still >>> working my way through it. >>> >>> I modified pki_create_instance to add both the Utimaco library and >>> the Coolkey PKCS11 libary. I had to turn off SELinux enforcement >>> to get Coolkey to show up on the list, but even then, the Utimaco >>> lib didn't. I haven't had a chance to go back and check again. >>> >>> Mike >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users > From msj at nthpermutation.com Wed Apr 28 02:20:54 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Tue, 27 Apr 2010 22:20:54 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD79665.2040202@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> <4BD794AF.3030401@nthpermutation.com> <4BD79665.2040202@strongauth.com> Message-ID: <4BD79B86.3000508@nthpermutation.com> On 4/27/2010 9:59 PM, Arshad Noor wrote: > When the Utimaco slots show up, do they consistently show up with > a Login button? If there is no Login button, what would be the > point of displaying the slot? One wouldn't be able to use it to > generate keys. > > Arshad Noor > StrongAuth, Inc. > They consistently show up with the Login button if I add them to the preop.configModules section (and they show up in the Supported section). They consistently do not have a login button if I only add them to the module database (so they show up in the unsupported section of the config page). I don't know why they don't show up with a Login button in the unsupported section of the page. Mike From arshad.noor at strongauth.com Wed Apr 28 02:41:07 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 27 Apr 2010 19:41:07 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD79960.3060400@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> <4BD794AF.3030401@nthpermutation.com> <4BD79960.3060400@nthpermutation.com> Message-ID: <4BD7A043.9090104@strongauth.com> Appreciate everything you're mentioning about this, Mike; can you clarify one last item? What do you mean by the following statement? Thanks. Arshad Noor StrongAuth, Inc. Michael StJohns wrote: > > > Add utimaco to the pkicreate script in /usr/bin From msj at nthpermutation.com Wed Apr 28 02:48:26 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Tue, 27 Apr 2010 22:48:26 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD7A043.9090104@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> <4BD794AF.3030401@nthpermutation.com> <4BD79960.3060400@nthpermutation.com> <4BD7A043.9090104@strongauth.com> Message-ID: <4BD7A1FA.8000703@nthpermutation.com> On 4/27/2010 10:41 PM, Arshad Noor wrote: > Appreciate everything you're mentioning about this, Mike; can you > clarify one last item? > > What do you mean by the following statement? Thanks. > > Arshad Noor > StrongAuth, Inc. > > Michael StJohns wrote: >> >> >> Add utimaco to the pkicreate script in /usr/bin Find the sections where nFast and Luna are added to the module by pkicreate - add similar language for Utimaco. From arshad.noor at strongauth.com Wed Apr 28 03:04:26 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 27 Apr 2010 20:04:26 -0700 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD7A1FA.8000703@nthpermutation.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> <4BD794AF.3030401@nthpermutation.com> <4BD79960.3060400@nthpermutation.com> <4BD7A043.9090104@strongauth.com> <4BD7A1FA.8000703@nthpermutation.com> Message-ID: <4BD7A5BA.1070404@strongauth.com> All it seems to be doing is adding the PKCS11 library to the secmod.db for the new instance it is creating - something one can do manually even after the instance has been created. You do have to restart the service so the servlet sees the new module in secmod.db, but I don't think it does anything else. Arshad Noor StrongAuth, Inc. P.S. How I miss the old Java installation wizard CS had; it was simple, elegant and allowed for significant configuration in the wizard. You could have an instance of a CA up and running in less than 5 minutes. Between rpm, perl scripts, HTML and servlets, the new installation process appears to have made installation one of the most complex parts of setting up a DogTag PKI. What a pity. Michael StJohns wrote: > On 4/27/2010 10:41 PM, Arshad Noor wrote: >> Appreciate everything you're mentioning about this, Mike; can you >> clarify one last item? >> >> What do you mean by the following statement? Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> Michael StJohns wrote: >>> >>> >>> Add utimaco to the pkicreate script in /usr/bin > > Find the sections where nFast and Luna are added to the module by > pkicreate - add similar language for Utimaco. > > From ehimawan at gmail.com Wed Apr 28 17:26:16 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Wed, 28 Apr 2010 12:26:16 -0500 Subject: [Pki-users] Reset pkiconsole "administrator" password? In-Reply-To: References: Message-ID: What do you mean to reset the "admin" password? Do you forgot the password? If you do, then you have to change it at the directory. If you want to change it, you can login to pkiconsole and there are "users and groups" where you can select a particular user to change the user's password. Erwin On Tue, Apr 27, 2010 at 7:53 PM, Mike Mercier wrote: > Hello, > > Is there a way to reset the pkiconsole "administrator" (I think the > username is actually 'admin') password? > Can someone point me to the documentation? > > Thanks, > Mike > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmercier at gmail.com Wed Apr 28 19:03:21 2010 From: mmercier at gmail.com (Mike Mercier) Date: Wed, 28 Apr 2010 15:03:21 -0400 Subject: [Pki-users] Reset pkiconsole "administrator" password? In-Reply-To: References: Message-ID: I thought I had forgot the 'admin' password (i.e. I could not 'login' using the pkiconsole application). I did manage to remember it (or maybe I was using 'Administrator' when I first tried), but I would still like to know if it is possible to reset the 'admin' password for pkiconsole without using the pkiconsole application. Thanks, Mike On Wed, Apr 28, 2010 at 1:26 PM, Erwin Himawan wrote: > What do you mean to reset the "admin" password? Do you forgot the password? > If you do, then you have to change it at the directory. If you want to > change it, you can login to pkiconsole and there are "users and groups" > where you can select a particular user to change the user's password. > > Erwin > > On Tue, Apr 27, 2010 at 7:53 PM, Mike Mercier wrote: > >> Hello, >> >> Is there a way to reset the pkiconsole "administrator" (I think the >> username is actually 'admin') password? >> Can someone point me to the documentation? >> >> Thanks, >> Mike >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ckannan at redhat.com Wed Apr 28 19:06:27 2010 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Wed, 28 Apr 2010 12:06:27 -0700 Subject: [Pki-users] Reset pkiconsole "administrator" password? In-Reply-To: References: Message-ID: <4BD88733.9040505@redhat.com> On 04/28/2010 12:03 PM, Mike Mercier wrote: > I thought I had forgot the 'admin' password (i.e. I could not 'login' > using the pkiconsole application). I did manage to remember it (or > maybe I was using 'Administrator' when I first tried), but I would > still like to know if it is possible to reset the 'admin' password for > pkiconsole without using the pkiconsole application. Yes. you just need to find out where the admin user uid=admin is located in the ldap tree. and just issue an ldap command to get the password changed as you would do for any other ldap user. --Chandra From msj at nthpermutation.com Wed Apr 28 19:09:11 2010 From: msj at nthpermutation.com (Michael StJohns) Date: Wed, 28 Apr 2010 15:09:11 -0400 Subject: [Pki-users] Utimaco HSM "Not Found" problem In-Reply-To: <4BD7A5BA.1070404@strongauth.com> References: <4BC7B428.7060808@strongauth.com> <4BC7C11D.9060209@nthpermutation.com> <4BD0A32F.7060800@strongauth.com> <4BD0B1BC.3020304@redhat.com> <4BD0BA3F.6000608@strongauth.com> <4BD0C4AC.2010904@redhat.com> <4BD0C63A.9060400@strongauth.com> <4BD0D0F7.7080305@strongauth.com> <4BD0DDE4.50600@redhat.com> <4BD0DF4C.8010708@strongauth.com> <4BD0E154.20304@redhat.com> <4BD0E23C.3070608@strongauth.com> <4BD5C47B.5010605@strongauth.com> <4BD5C4FE.6030902@redhat.com> <4BD65001.3070102@redhat.com> <4BD78408.9050105@nthpermutation.com> <4BD78681.90602@strongauth.com> <4BD794AF.3030401@nthpermutation.com> <4BD79960.3060400@nthpermutation.com> <4BD7A043.9090104@strongauth.com> <4BD7A1FA.8000703@nthpermutation.com> <4BD7A5BA.1070404@strongauth.com> Message-ID: <4BD887D7.9040206@nthpermutation.com> On 4/27/2010 11:04 PM, Arshad Noor wrote: > All it seems to be doing is adding the PKCS11 library to the > secmod.db for the new instance it is creating - something one > can do manually even after the instance has been created. Right - but if you modify both of these files and use the same "name" for the module for both then this gets picked up in the Supported Module section of the page. Alternately, run the unmodified pkicreate, modify CS.cfg, stop the server, add the module manually and restart the server. Make sure you use the same name..... Mike > > You do have to restart the service so the servlet sees the new > module in secmod.db, but I don't think it does anything else. > > Arshad Noor > StrongAuth, Inc. > > P.S. How I miss the old Java installation wizard CS had; it > was simple, elegant and allowed for significant configuration > in the wizard. You could have an instance of a CA up and > running in less than 5 minutes. Between rpm, perl scripts, > HTML and servlets, the new installation process appears to > have made installation one of the most complex parts of > setting up a DogTag PKI. What a pity. > >