Certificate Authority – Generate CA Signed ECDSA Certificate

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:

  basicConstraints=CA:TRUE
  certificatePolicies=2.5.29.32.0
  

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.

Have a look at this Q/A over on Information Security SE:

Is possible that a TLS server send more than one certificate to the client for the same site?

Strictly speaking, the server can send an arbitrary number of certificates to the client, as part of its Certificate message. However, as the standard says:

The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it.

Therefore, a really compliant server cannot send a choice of certificates to the client, and cannot expect clients to use any other certificate than the first one they send.

For signature algorithm support, there is a standard TLS extension specified in section 7.4.1.4.1, by which the client can tell to the server, early in the handshake (in the ClientHello, which is the very first message of the procedure), which hash functions and signature algorithms it supports. This allows a server who owns, for instance, both a RSA-signed certificate and an ECDSA-signed certificate, to send one or the other, depending on what the client supports. This is typical of how things go in TLS: the client suggests, the server chooses.

(In practice, support for this extension is not yet widespread. But, also in practice, everybody uses RSA and supports RSA.)