I've read the answer to the following "Checklist on building an Offline Root & Intermediate Certificate Authority (CA)" and I have one questions based on the system I am trying building
It's an Windows 2008 system with 3 domains/forest (That is one domain per forest) I wish to use certificates within this and belive I should be able to do so with a single self signed offline room.

  • ROOT - is the CA = Self Signed Offline Root
  • DOM1IntRoot is the CA for the Active directory domain DOM1.A.COM
  • DOM2IntRoot is the CA for the Active directory domain DOM2.A.COM
  • DOM23IntRoot is the CA for the Active directory domain DOM3.DOM2.A.COM

There are no trusts, no subdomains So what I'd like to do is sign DOM1IntRoot, DOM2IntRoot and DOM3IntRoot with ROOT so that I only need one offline root
So that means I need to install the ROOT CA certificate into each domain - which I think from the Microsoft "Example Scenario for Contoso" means I need to set the LDAP AIA location to a configuration partition which exists in all domains (in this case DC=a,DC=com ) and the HTTP location to some single server . However, it also says that they can have seperated CRL/AIA locations which seems contradictory

So then I read the answer referenced above and says leave the AIA/CRL blank. Which seems to imply that the DOM1IntRoot, DOM2IntRoot , DOM3IntRoot will be publishing the CRL/AIA for the ROOT

So I have two possible answers either the ROOTCA has CRL/AIA or it doesnt. If the ROOTCA has AIA/CRL then what exactly should I specify for the LDAP/HTTP and FILE URLS for AIA and the CRL locations eg is this correct?

ldap:///CN=ROOTCA<CRLNameSuffix>,CN=ROOTCA,CN=CDP,CN=Public Key Services,CN=Services,DC=A,DC=COM

Where <SOMESERVER> is a server with IIS which will make the Certificates abvailable

Note that I am NOT using the offline roots servers name as its never seen- is that correct?

If the ROOTCA does not have AIA/CRL then how do I publish a revocation of (say) DOM1IntRoot?

I'm a little confused so this question may be starting from completely the wrong assumptions

I'll add a little information on the domain structure to try and head off some questions - DOM1.A.COM is where the clients set - DOM2.A.COM is a DMZ type network protecting DOM3 - DOM3.DOM2.A.COM is only accessed but users from DOM1 remotely logging into DOM2 and then another remote session in DOM3 - We wish to use certificates for the seesions between DOM1 and DOM2 and DOM2 and DOM3 - We also will be using certificates from DOM2 to the network devices (It probably should be DOM3 but thats still being discussed) - DOM2 and DOM3 are isloated from the internet. DOM3 is isloated from everything except DOM2

1 Answer 1


If the root CA is offline then the root CA is offline: it has no network. This implies that whenever a CRL is published, a manual intervention is needed to put it on a connected host. At that point, you can put it manually in three places if need be.

The "Authority Information Access" (AIA) and "CRL Distribution Points" (CRLDP) extensions are information which is written in the certificates issued by the CA. In that case, these extensions are in the CA certificates issued to the subordinate CA (the three subdomain CA). There is no requirement that each sub-CA receives the exact same AIA and CRLDP from the root; you could perfectly arrange for the root to issue the certificate for CA1 with an AIA and CRLDP pointing to locations (ldap:// URL) in the forest for DOM1.A.COM, where you will manually push a copy of the root CA certificate and the CRL produced by the root CA. Ditto for CA2, but this time with locations in DOM2.A.COM, and so on.

However, it is probably simpler to use HTTP. Put a Web server somewhere accessible from all the domains, and have the root CA write in the certificates it issue some AIA and CRLDP with http:// URL. Plain HTTP is fine for certificates and CRL, which are signed object, and thus can be distributed with no regard for any kind of security (no need of HTTPS or whatsnot for certificate and CRL publication).

Also, the AIA is not very useful for a root CA because it is a root: validation will work only if whoever validates trusts the root a priori, so it must already know it. AIA is for locating certificates which you do not know a priori, and, therefore, certificates which you do not trust a priori: very useful for intermediate CA, quite useless for root CA. In an Active Directory context, you can push the root CA as "trusted" through, for instance, some GPO.

To automate CRL publication, you could use a mostly offline root CA. That's a root CA which is offline except that it has an inherently one-way channel to output regularly produced CRL. I have done it once over an audio cable (CRL encoded as sound, decoded on the other side): the advantage is that the "out" jack from the audio interface of a server is physically distinct from the "in" jack (the "out" is green, the "in" is pink), so it can be visually ascertained that the root is still offline. Other people have used RJ45 cables with only one pair of wires connected, which has better bandwidth but is less easily visually inspected.

Anyway, it does not change the root of the thing, which is that HTTP will make your life simpler.

  • 3
    The Audio cable solution is very interesting! Do you have any more details on this? Nov 16, 2012 at 12:47
  • One thing I discovered about publishing CRLs in LDAP vs HTTP is that Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients. Another reason to not use LDAP is because the revocation window can be smaller since there is no dependency on AD replication which can take 24-48 hours or more. Nov 16, 2012 at 13:04
  • After all this time - I've finally implemented an offline and two online CAs, pretty much as you say (AD publishing the offline certificate) no AIA - as it makes no sense and with a CRL which is manually published
    – Ross
    Oct 13, 2017 at 8:10
  • I am trying to design a Offline Root CA (ORCA) for use with multiple forests that have no trust. I just want to confirm, one option is that I could clear out and update the AIA & CDP http URLs each time I issue or renew a Subordinate CA within the forest so that they resolve to http URLs existing in that environment? ex.) on ORCA clear AIA & CDP and update with HTTP URLs matching Forest1 and then setup Forest1->SubCA1. Next on ORCA clear AIA & CDP and update with HTTP URLs matching Forest2 and then setup Forest2->SubCA1. This way the Root Certificate used on each Forest has a single HTTP URL.
    – Mausimo
    Jan 5 at 21:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .