I want to setup a enterprise certification authority for my domain. So I can issue certificates for various purposes. I would like to follow the best practice of having an offline CA as the root, and setup my enterprise CA as a subordinate. But it seems silly to license a fully copy of Windows for this task.

What I am hoping to be able to do is to install some live distribution onto a USB flash disk, and then install openssl, and setup my CA on flash drive. When I am ready to build the root key/cert I will disconnect the computer from the network, and then never use that USB disk on a network attached computer again.

Will I be able to properly sign and create a subordinate CA certificate for a Windows enterprise CA, that will be usable. What options do I need to use with OpenSSL to build the CA and sign the subordinate CA certificate properly.

I have attempted searched the web, and the this was the only thing I could find on the subject. But it predates 2008, and I am not entirely sure the person was every successful.

  • To be clear, The tool doesn't necessarily have to be be OpenSSL, but I do not want to run a huge CA like EJBCA. I am looking for an very light weight CA that can be run in a livecd/liveusb environment. – Zoredache Sep 27 '11 at 18:10

Yup, it works just fine; a Windows certificate authority has no qualms about running as a subordinate to a non-Windows root.

Tested with an OpenSSL root and a Windows 2008 R2 subordinate in Enterprise mode.

A couple things to play nice with what the MS CA expects in the OpenSSL config:

  • Valid AIA and CDP locations should apply to the root certificate, in the section configured by the x509_extensions property of the [req] section for the self-signed root. Something along these lines:

    authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
    crlDistributionPoints = URI:http://test-rootca.test.local/root.crl
  • A given OpenSSL config probably doesn't allow subordinate CAs by default. Change that for signed requests (make sure this isn't in place for requests that shouldn't be CAs, of course). This will be in the section configured by the x509_extensions property of the [ca] section:


So, we'll do a CA to test.

Make your root:

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

Fiddle with your config and create the necessary files and directories in the [ca] section of your OpenSSL config.

All set to get the Microsoft side of things going; create a Windows subordinate CA with manual signing.

Upload the certificate request to the OpenSSL server. While you're at it, download the root certificate. Import it into the trusted roots store - of the computer, not your user!

Issue the subordinate certificate:

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

If that didn't work, your CA probably has an issue with the config - new certs directory, index file, serial file, etc. Check the error message.

If it went, then that's it. If you haven't, make a CRL and put it in the CDP that you configured above; I just installed Apache and jammed it in webroot:

openssl ca -gencrl -out /var/www/root.crl

And put your certificate in the AIA location, if it isn't already:

cp /etc/ssl/certs/root.pem /var/www/root.pem

Download the newly issued subordinate certificate and install it to the CA with the Certification Authority MMC snap-in. It'll gripe about any issues with trust or validation, but it has no moral objection to taking it.

End result; a working Windows CA with no complaining from the Enterprise PKI snap-in, with a telltale OpenSSL Generated Certificate in the attributes.



I see what you are getting at, but I don't think OpenSSL is quite the tool for the job. You might want to look at Open Source Certificate Authority projects such as EJBCA which are more focussed on this functionality than OpenSSL, and have specific documentation you can use.

I don't see a reason why the concept wouldn't work, since all you are doing is signing the subordinate CA's certificate. If you were paying a public CA to do this for you, you wouldn't necessarily know or care what flavour of server they were using.

All you need to care about is:

  • you can sign the certificate from the CSR generated by your subordinate
  • the result can be installed on the subordinate itself
  • you have a root signing certificate that can be installed as trusted on whatever clients you are targeting
  • you can generate a revocation list that is served up somewhere

I can't say I have done this, but I am sure if you follow the docs for generating a CSR from a windows box, then follow your CA docs for generating a .p7k cert from a CSR, then you should be fine.

By the way - I would recommend you create your CA as a virtual machine for a popular hypervisor such as Hyper-V or VMware, rather than a boot disk, make sure you store it very securely somewhere your successor can find it, and spin it up offline periodically to make sure it runs, or transfer it to new media/technology. A root CA may have a life of 10 or 20 years...

  • +1 OpenSSL isn't the premier tool for creating a CA, but it does work in general. I haven't issued a sub-CA cert for a Windows Enterprise CA, but can't imagine why it wouldn't work (though MS has committed more egregious anti-competitive acts in the past). Big +1 for CA as VM. Keeping a second copy of the root cert is a good idea (Base64 on paper is very durable and easy to keep in a safe/deposit-box/etc) – Chris S Feb 7 '11 at 21:54
  • I was pretty pleased with myself when I realised I could set up a VM without any NICs and just use a virtual floppy drive to get CSRs on and signed certs off. Sneakernet reborn with a 21st Century Virtual shine! – dunxd Feb 7 '11 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.