Ok, that's better now. You have a number of issues here:
Wrong Issuer "Certificate (0)" Time: 0
[0.0] ldap:///CN=example-TESTPKI-CA,CN=AIA,CN=Public%20Key%20Services,
Services,CN=Configuration,DC=example,DC=com?cACertificate?base?objectCla
certificationAuthority
This error indicates that wrong subCA certificate is published in Active Directory. You will have to republish subCA certificate to Active Directory by running the following command:
certutil -dspublish -f SubCA.cer SubCA
Now your root CA:
Failed "AIA" Time: 0
Error retrieving URL: The request is not supported. 0x80070032 (WIN32: 50
ROR_NOT_SUPPORTED)
testpki.example.com/crld/root.cer
you mistyped the URL in OpenSSL config. Protocol prefix is missing. You need to add http://
prefix and reissue SubCA certificate.
Failed "CDP" Time: 0
Error retrieving URL: Not found (404). 0x80190194 (-2145844844 HTTP_E_STA
_NOT_FOUND)
http://testpki.example.com/crld/rootca.crl
This URL seems correct (at least, it includes protocol prefix), CA server can access web server, but web server responds with 404, indicating that there is nothing at requested path.
TBH, your setup is not good at all. Too many issues you have, because (as it seems), the design wasn't planned or plan wasn't verified.
Apart from explicit issues, your root CA itself includes CRL Distribution Points (CDP) and Authority Information Access (AIA) extensions, which are redundant. You should remove them from root certificate. AIA is not used in order to avoid cycles during path building. CDP in root certificates is not used, because you can't revoke root (self-signed) certificate, because of chicken-egg issue. But they (CDP and AIA extensions) must be included in issued certificate (i.e. subordinate CA).
I would recommend to roll back all you have done here and start from scratch.
First of all, you need to design your solution, plan all aspects.
- Identify applications which will use certificates.
- Describe certificate requirements and plan the scope of certificates.
- Based on [2] identify certificate templates and their configuration you will use.
- Design CA placement diagram and create certificate flow diagram (certificate enrollment, validation by client applications).
- Design disaster recovery plan, which will include backup and restore plan.
Otherwise, your solution will worth nothing. Even if this is test deployment, you still have to pass all these steps.
Properly plan CRT/CRL publishing and download URLs. You will need to check it twice, because these issues can't be fixed easily without having to re-deploy all certificates. General suggestions on this subject:
- do not use LDAP URLs in CDP/AIA. Consider to use HTTP only.
- use dedicated web server to serve CRT/CRL files (do not combine SubCA with web server roles).
- do not use CDP/AIA extensions in root certificate
- make sure that CRT/CRL files are accessible by all clients (which will use your certificates)
On CDP/AIA extension planning I would suggest to check my blog post: Designing CRL Distribution Points and Authority Information Access locations. Although, the article was written against Microsoft CA, the same principles apply to any other CA implementation, because these are best practices.
Best Answer
Microsoft specifies that the offline root CA machine should not be a member of a domain, so it's not going to cause you any problems, and it makes the whole issue of AD tombstone lifetime issues moot. To wit:
I haven't attempted extensive interoperability testing with OpenSSL and the Windows CA but, in principle, it should work fine-- it's all standards-based PKI. Certainly, I've signed certs for Windows servers using OpenSSL many, many times w/ no ill effects. As long as you're comfortable using the OpenSSL tools to issue the certs for your second tier CAs it won't cause you any specific management issues.
I see no particular value from deploying the root CA using one set of tools and the intermediate(s) on another. You certainly can, but I don't see how that "buys" you anything.