My understanding is that you can only have one ADCS instance per host and up to 3 CAs in the AD Forest. The "\CA Name" is more about the name of your PKI Tree and should not be confused with \INST1 type instances seen in MSSQL Configuration, which is what I think you may be thinking of.
It would be good practice to keep your CAs separated, because if all were on one host, should the host be compromised all CAs on the host are compromised.
If you had multiple PKI trees in your Forest, your would see multiple entries from certutil.
There is the ability to decouple the Enrolment Policy server using the Web Policy Enrolment Server - useful for DMZ Environments where you need to issue certificates externally.
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
You should not have problems. Your configuration just mean that your CRL file should be called myrootca.crl. As long as it stays updated and persists it's name, clients successfully can check it.
You can not change CDP extension for already issued certificates. But if you will change URL of CDP point, all new certificates from that moment will perform revocation check using new URL. After changing CDP URL you need to ensure that CRL will be published also to the old URL with myrootca.crl name, so old certificates could perform revocation check too.
Also be sure that your CDP list is not enclude more than two CDP points, because in this case revocation check will faile due a timeout.