Having dealt with the same scenario, here's an overview of the approach that I took:
Get the new environment up and running, but don't give it any ability to issue certificates - use LoadDefaultTemplates=False
in your capolicy.inf.
While the devices are still set to not issue any templates, get everything squared away with the new environment, AIA locations, CRL distribution, etc. Check health of all with the Enterprise PKI snap-in.
Then, when you're ready, alter the config of the existing CA to stop issuing certificates for certain templates. You aren't killing the server yet, just telling it to stop issuing new certs. Add those same templates to the allowed issuance policies of your new environment.
Then, use the "re-enroll certificate holders" option on the template management tool for the templates that have certificates out there and are auto-enrolled (user, computer, and domain controller certs). This will bump the template version and cause them to grab a new certificate from the new infrastructure when their autoenroll pulses.
This will cover you for those certs, but for web server certs it'll unfortunately be a manual process. Re-issue for each, and change listeners to the new certs.
Once you're fairly confident that you've got all the certificates re-issued, cripple the old CA but don't remove the role yet. Do something along the lines of removing all AIA or CRL distribution points in the CA's configuration, then deleting the files/objects from those locations (LDAP is probably the main one, but http and smb need checking too). Wait for issues for a few weeks; when something breaks, you can re-add the AIA/CRL points that you deleted and re-publish (certutil -dspublish
) if needed.
Once you're satisfied that nothing's using the old CA anymore, remove the role, then clean up Active Directory. The AIA, CRLs, and delta CRLs need a manual delete, which you can do in the "Manage AD Containers" option in the Enterprise PKI snap-in.
Keeping the same private key on your root CA allows for all certificates to continue to validate successfully against the new root; all that's required of you is to trust the new root.
The certificate signing relationship is based on a signature from the private key; keeping the same private key (and, implicitly, the same public key) while generating a new public certificate, with a new validity period and any other new attributes changed as needed, keeps the trust relationship in place. CRLs, too, can continue over from the old cert to the new, as they are, like certificates, signed by the private key.
So, let's verify!
Make a root CA:
openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes
Generate a child certificate from it:
openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr
Sign the child cert:
openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr
All set there, normal certificate relationship. Let's verify the trust:
# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK
Ok, so, now let's say 10 years passed. Let's generate a new public certificate from the same root private key.
openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr
And.. did it work?
# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK
But.. why? They're different files, right?
# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020 newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899 origroot.pem
Yes, but, that doesn't mean that the new public key doesn't cryptographically match the signature on the certificate. Different serial numbers, same modulus:
# openssl x509 -noout -text -in origroot.pem
Serial Number:
c0:67:16:c0:8a:6b:59:1d
...
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
Serial Number:
9a:a4:7b:e9:2b:0e:2c:32
...
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
d7:a3:66:0a:45:bd:0e:cd:9d
Let's go a little further to verify that it's working in real world certificate validation.
Fire up an Apache instance, and let's give it a go (debian file structure, adjust as needed):
# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/
We'll set these directives on a VirtualHost
listening on 443 - remember, the newroot.pem
root certificate didn't even exist when cert.pem
was generated and signed.
SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem
Let's check out how openssl sees it:
# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443
Certificate chain
0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)
Ok, and how about a browser using MS's crypto API? Gotta trust the root, first, then it's all good, with the new root's serial number:
And, we should still be working with the old root, too. Switch Apache's config around:
SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem
Do a full restart on Apache, a reload won't switch the certs properly.
# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443
Certificate chain
0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)
And, with the MS crypto API browser, Apache's presenting the old root, but the new root's still in the computer's trusted root store. It'll automatically find it and validate the cert against the trusted (new) root, despite Apache presenting a different chain (the old root). After stripping the new root from trusted roots and adding the original root cert, all is well:
So, that's it! Keep the same private key when you renew, swap in the new trusted root, and it pretty much all just works. Good luck!
Best Answer
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: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:
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:
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:
And put your certificate in the AIA location, if it isn't already:
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.