OpenSSL with Windows subordinates
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?
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
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
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
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
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]
Newca error, -create_serial
Let me preface first by saying I did see some previous users had this problem also. I've even gone so far as to completely wipe the system and start fresh only to have the same issue. Running a FreeBSD 6.2 server with OpenSSL 0.9.8d. After I do the installation, I execute the CA.pl -newca option. After I enter the information, it gives me the "unknown option -create_serial" error. I'm using the root account on this machine to keep it simple, which defaults to csh. By default the openssl installation has placed it in the /usr/local/ssl directory, so I added /usr/local/ssl/misc to the PATH in .cshrc and still receive the same error. Any suggestions? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Openssl root and subordinate, CA creation problem
I've setup an openssl root and a subordinate CA. I have successfully signed CA certificate for the subordinate from the root (used the -newreq option), however when I execute the 'ca.pl -newca' it doesn't set up the subordinate authority at all. When it asks for the CA certificate filename, I point it to the signed certificate but it immediately terminates after that not giving any errors. I could just hit enter but then that would make the subordinate think it needs to self-sign its certificates. Do I have my steps mixed up?
Custom oid in openssl.cnf
A quick question for everyone... In the openssl.cnf, by default there is a new_oids section with a testoid line to serve as an example. So if I have a unique assigned oid, can I just remove the # on the testoid1 line? I recall reading someone mentioning using a line of dc=(oid number) instead. Which one is correct?
