RE: OpenSSL with Windows subordinates
Wonderful! I redid the root CA setup using ca.pl, modified the openssl.cnf file to CA:TRUE in the v3_ca section, and signed the subordinate request using the previous command: (ca -config /path/openssl.cnf -out thecertificate.pem -in requestfile.req -extensions v3_ca). I imported the the pem file for the subordinate, and also the root cert, and the Windows services started up just fine. I was also able to verify its functionality by requesting some user certs from it. Is there much difference between signing with the openssl command above and the ca.pl perl script? It seems to me it is mainly helpful for automating the process. One last question if you don't mind. I noticed the keysize for my subordinate is 1024 bits. Where can I indicate the keysize when signing the request? In the openssl.cnf file I used, I have 4096 listed in the req section, but does this need to be placed elsewhere? It didn't work when I placed it in the v3_ca section. Thanks, Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Thursday, December 28, 2006 15:47 To: openssl-users@openssl.org Subject: Re: OpenSSL with Windows subordinates Yes the root CA has basicConstraints CA:FALSE on it which is causing the error. I'd suggest you redo the root CA and the subordinate using CA.pl: CA.sh is an older script that isn't maintained any more. The command CA.pl -signCA automatically signs a request as a CA instead of an end entity cert. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL with Windows subordinates
On Fri, Dec 29, 2006, Aaron Barnes wrote: Wonderful! I redid the root CA setup using ca.pl, modified the openssl.cnf file to CA:TRUE in the v3_ca section, and signed the subordinate request using the previous command: (ca -config /path/openssl.cnf -out thecertificate.pem -in requestfile.req -extensions v3_ca). I imported the the pem file for the subordinate, and also the root cert, and the Windows services started up just fine. I was also able to verify its functionality by requesting some user certs from it. Is there much difference between signing with the openssl command above and the ca.pl perl script? It seems to me it is mainly helpful for automating the process. Yes that's its main point: to make it easier to setup the appropriate file structure and perform some common operations without having to delve into the complexities of some of the commands. One last question if you don't mind. I noticed the keysize for my subordinate is 1024 bits. Where can I indicate the keysize when signing the request? In the openssl.cnf file I used, I have 4096 listed in the req section, but does this need to be placed elsewhere? It didn't work when I placed it in the v3_ca section. The key is contained in the request so when it is signed it uses whatever key is present. So if you want a larger key size you'll need to redo the request. If the root CA also has a key size of 1024 bits you should increase that too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL with Windows subordinates
I think we're making some progress with resolving this problem. I signed a new request with the switch you mentioned and loaded it onto the subordinate. I don't receive the old ASN1 error, which is good, but now I've received one I've never seen before, A certificate's basic constraint extension has not been observed. Does this mean I may have something configured incorrectly in the openssl.cnf file? One bit of good news though is that I no longer have to export the certificate into .der format; the .pem file worked just fine. Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Wednesday, December 27, 2006 15:04 To: openssl-users@openssl.org Subject: Re: OpenSSL with Windows subordinates Yes the signing command is incorrect. By default the certificate is an end entity certificate for OpenSSL not a CA certificate. Try the command line switch: -extensions v3_ca Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL with Windows subordinates
On Thu, Dec 28, 2006, Aaron Barnes wrote: I think we're making some progress with resolving this problem. I signed a new request with the switch you mentioned and loaded it onto the subordinate. I don't receive the old ASN1 error, which is good, but now I've received one I've never seen before, A certificate's basic constraint extension has not been observed. Does this mean I may have something configured incorrectly in the openssl.cnf file? Did you install a root CA onto that system too? If so that might be a problem depending on how you created it. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL with Windows subordinates
Yes I did. I had to install that yesterday also in order for the subordinate to trust the root. I was reading on the web site (specifically on this web page: http://www.openssl.org/docs/apps/x509v3_config.html# ) It would seem to indicate one should modify the basicConstraints lines in the openssl.cnf file, but again I am not terribly familiar with this option. The only things I have modified in my openssl.cnf file so far are the lines to include email address, location, directory structure , changed policy fields to optional, and the key size. If I am understanding this correctly, the OpenSSL root issued the certificate as a simple 'machine' cert, not as a subordinate CA. Am I on the right track? Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Thursday, December 28, 2006 11:55 To: openssl-users@openssl.org Subject: Re: OpenSSL with Windows subordinates On Thu, Dec 28, 2006, Aaron Barnes wrote: I think we're making some progress with resolving this problem. I signed a new request with the switch you mentioned and loaded it onto the subordinate. I don't receive the old ASN1 error, which is good, but now I've received one I've never seen before, A certificate's basic constraint extension has not been observed. Does this mean I may have something configured incorrectly in the openssl.cnf file? Did you install a root CA onto that system too? If so that might be a problem depending on how you created it. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL with Windows subordinates
On Thu, Dec 28, 2006, Aaron Barnes wrote: Yes I did. I had to install that yesterday also in order for the subordinate to trust the root. I was reading on the web site (specifically on this web page: http://www.openssl.org/docs/apps/x509v3_config.html# ) It would seem to indicate one should modify the basicConstraints lines in the openssl.cnf file, but again I am not terribly familiar with this option. The only things I have modified in my openssl.cnf file so far are the lines to include email address, location, directory structure , changed policy fields to optional, and the key size. If I am understanding this correctly, the OpenSSL root issued the certificate as a simple 'machine' cert, not as a subordinate CA. Am I on the right track? If you used the CA.pl script to generate the certificates it should just do the right thing. The standard openssl.cnf has some sensible defaults which should suit most purposes. That includes using basicConstraints for a CA certificate. If you've used other commands (all manner of weird stuff is recommended by some cookbooks) then the certificates may not suit your purpose. If you do: openssl x509 -in cert.pem -text -noout you should see the basicConstraints extension. It must have CA:TRUE for both the root CA and the subordinate. If that doesn't help just post (or mail me privately) with the two certificates you have created. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL with Windows subordinates
I think I see what you're getting at now. I reviewed the text of the root and the subordinate certs; the root does NOT have the CA:TRUE (false obviously), the subordinate does have CA:TRUE. So I guess this tells me I must have installed the root CA incorrectly. I didn't use CA.pl, but rather CA.sh. I'll list each step I did to set up OpenSSL and the root. 1. ./config 2. make 3. make test 4. make install 5. ./CA.sh -newca 6. ./CA.sh -sign It sounds like I'll probably need to redo the root setup, but let me know if there is an adjustment I need to make based on how many tiers I want to set up in the overall PKI. I'll also email you copies of the certificates separately. Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Thursday, December 28, 2006 12:34 To: openssl-users@openssl.org Subject: Re: OpenSSL with Windows subordinates If you used the CA.pl script to generate the certificates it should just do the right thing. The standard openssl.cnf has some sensible defaults which should suit most purposes. That includes using basicConstraints for a CA certificate. If you've used other commands (all manner of weird stuff is recommended by some cookbooks) then the certificates may not suit your purpose. If you do: openssl x509 -in cert.pem -text -noout you should see the basicConstraints extension. It must have CA:TRUE for both the root CA and the subordinate. If that doesn't help just post (or mail me privately) with the two certificates you have created. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL with Windows subordinates
On Thu, Dec 28, 2006, Aaron Barnes wrote: I think I see what you're getting at now. I reviewed the text of the root and the subordinate certs; the root does NOT have the CA:TRUE (false obviously), the subordinate does have CA:TRUE. So I guess this tells me I must have installed the root CA incorrectly. I didn't use CA.pl, but rather CA.sh. I'll list each step I did to set up OpenSSL and the root. 1. ./config 2. make 3. make test 4. make install 5. ./CA.sh -newca 6. ./CA.sh -sign It sounds like I'll probably need to redo the root setup, but let me know if there is an adjustment I need to make based on how many tiers I want to set up in the overall PKI. I'll also email you copies of the certificates separately. Yes the root CA has basicConstraints CA:FALSE on it which is causing the error. I'd suggest you redo the root CA and the subordinate using CA.pl: CA.sh is an older script that isn't maintained any more. The command CA.pl -signCA automatically signs a request as a CA instead of an end entity cert. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL with Windows subordinates
Don't forget Path Length. -Kyle H On 12/28/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Thu, Dec 28, 2006, Aaron Barnes wrote: Yes I did. I had to install that yesterday also in order for the subordinate to trust the root. I was reading on the web site (specifically on this web page: http://www.openssl.org/docs/apps/x509v3_config.html# ) It would seem to indicate one should modify the basicConstraints lines in the openssl.cnf file, but again I am not terribly familiar with this option. The only things I have modified in my openssl.cnf file so far are the lines to include email address, location, directory structure , changed policy fields to optional, and the key size. If I am understanding this correctly, the OpenSSL root issued the certificate as a simple 'machine' cert, not as a subordinate CA. Am I on the right track? If you used the CA.pl script to generate the certificates it should just do the right thing. The standard openssl.cnf has some sensible defaults which should suit most purposes. That includes using basicConstraints for a CA certificate. If you've used other commands (all manner of weird stuff is recommended by some cookbooks) then the certificates may not suit your purpose. If you do: openssl x509 -in cert.pem -text -noout you should see the basicConstraints extension. It must have CA:TRUE for both the root CA and the subordinate. If that doesn't help just post (or mail me privately) with the two certificates you have created. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL with Windows subordinates
On Wed, Dec 27, 2006, Aaron Barnes wrote: I have an OpenSSL CA running on a BSD 6.1 machine as the root, and am trying to have that act as the parent to subordinate Windows online enterprise CAs. The installation went fine. I signed the Windows subordinate CA cert request with SSL, then converted it to pkcs12 to be installed. That's where I get the problem. When I try to installed the pkcs12 cert on the Windows machine, it doesn't like it, giving me an ASN1 unexpected end of data. I suspect that possibly it is because it isn't seeing the private key when OpenSSL converts to pkcs12. I was actually only able to get the .pem - .p12 conversion to work by using the -nokeys option. So let me walk you through each step. 1. Received Windows CA generated request file (.der). 2. Signed it using ca -config blahblah/openssl.cnf -in windowsreqfile.der -out newcert.pem 3. Converted it using pkcs12 -export -in newcert.pem -out newercert.p12 -nokeys So as I said I could only get the conversion command to work using the nokeys option. If I didn't, it would error out on me saying unable to load private key. This tells me I may have missed a step in the signing process, but I'm unsure what exactly. Do I need to execute another command after step 2 to output a separate private key file? Shouldn't the private key be included in the .pem file in step 2? The private key resides on the Windows machine and doesn't leave it which is as it should be. A PKCS#12 file is only really used when the private key and matching certificate are present. You really need to just install the certificate and have Windows associate the key with it. How you do that depends on exactly what you did in Step #1. You may be able to just install the newcert.pem file or you can convert it to DER using: openssl x509 -in newcert.pem -outform DER -out newcert.der Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL with Windows subordinates
With Windows certificate services, upon installation it will ask you to select the type of CA the server is to become from 4 different options. I've chosen an enterprise online CA, however its parent is offline, so of course I cannot make an online certificate request. I saved the actual certificate request as a .der file (Windows defaults to .req I believe) and copied to the OpenSSL parent box. Perhaps my signing command was in error. I used ca -config /pathtoconfigfile/openssl.cnf -out thecertificate.pem -in windowsrequestfile.der. When installing the subordinate's certificate, it does not like .pem files...which doesn't really surprise me. The available options are .cer, .crt, .p12, .pfx and .p7b. I was using pkcs12 as it indicated there was an available export option for that command. When I tried to use the .pem file it would give me the error The certificate is not a CA certificate. I also executed the command you suggested and tried installing the .der file; it gives the same error. Regards, Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Wednesday, December 27, 2006 11:24 To: openssl-users@openssl.org Subject: Re: OpenSSL with Windows subordinates The private key resides on the Windows machine and doesn't leave it which is as it should be. A PKCS#12 file is only really used when the private key and matching certificate are present. You really need to just install the certificate and have Windows associate the key with it. How you do that depends on exactly what you did in Step #1. You may be able to just install the newcert.pem file or you can convert it to DER using: openssl x509 -in newcert.pem -outform DER -out newcert.der Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL with Windows subordinates
On Wed, Dec 27, 2006, Aaron Barnes wrote: With Windows certificate services, upon installation it will ask you to select the type of CA the server is to become from 4 different options. I've chosen an enterprise online CA, however its parent is offline, so of course I cannot make an online certificate request. I saved the actual certificate request as a .der file (Windows defaults to .req I believe) and copied to the OpenSSL parent box. Perhaps my signing command was in error. I used ca -config /pathtoconfigfile/openssl.cnf -out thecertificate.pem -in windowsrequestfile.der. When installing the subordinate's certificate, it does not like .pem files...which doesn't really surprise me. The available options are .cer, .crt, .p12, .pfx and .p7b. I was using pkcs12 as it indicated there was an available export option for that command. When I tried to use the .pem file it would give me the error The certificate is not a CA certificate. I also executed the command you suggested and tried installing the .der file; it gives the same error. Yes the signing command is incorrect. By default the certificate is an end entity certificate for OpenSSL not a CA certificate. Try the command line switch: -extensions v3_ca Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
