A root certification authority (CA) is the top of a public key infrastructure (PKI) and generates a self-signed certificate. This means that the root CA is validating itself (self-validating). This root CA could then have subordinate CAs that effectively
trust it. The subordinate CAs receive a certificate signed by the root CA, so the subordinate CAs can issue certificates that are validated by the root CA. This establishes a CA hierarchy and trust path.
If a root CA is in some way compromised (broken into, hacked, stolen, or accessed by an unauthorized or malicious person), then all of the certificates that were issued by that CA are also compromised. Since certificates are used for data protection, identification,
and authorization, the compromise of a CA could compromise the security of an entire organizational network. For that reason, many organizations that run internal PKIs install their root CA offline. That is, the CA is never connected to the company network,
which makes the root CA an offline root CA. Make sure that you keep all CAs in secure areas with limited access.
To ensure the reliability of your CA infrastructure, specify that any root and non-issuing intermediate CAs must be offline. A non-issuing CA is one that is not expected to provide certificates to client computers, network devices, and so on. This minimizes
the risk of the CA private keys becoming compromised, which would in turn compromise all the certificates that were issued by the CA.
↑ Return to Top
Offline root CAs can issue certificates to removable media devices (e.g. floppy disk, USB drive, CD/DVD) and then physically transported to the subordinate CAs that need the certificate in order to perform their tasks. If the subordinate CA is a non-issuing
intermediate that is offline, then it will also be used to generate a certificate and that certificate will be placed on removable media. Each CA receives its authorization to issue certificates from the CA directly above it in the CA hierarchy. However, you
can have multiple CAs at the same level of the CA hierarchy. Issuing CAs are typically online and used to issue certificates to client computers, network devices, mobile devices, and so on.
Most organizations will find that a two-level, (typically referred to as a two-tier), CA hierarchy is appropriate. In a two-tier CA hierarchy, there will is a single offline root CA and any number of issuing CAs authorized by that root CA. The root CA is
never placed on the network, as previously described. CA hierarchies might go to three or more levels in some organizations. For more information on CA hierarchy planning, see the resources listed under the Plan section of the Windows PKI documentation reference
Since offline CAs should not be connected to a network, it does not make sense to join them to an Active Directory Domain Services (AD DS) domain, even with the
Offline Domain Join option introduced with Windows 7 and Windows Server 2008 R2. Furthermore, installing an offline CA on a server that is a member of a domain can cause problems with a secure channel when you bring the CA back online after a long offline
period. This is because the computer account password changes every 30 days. You can get around this by problem and better protect your CA by making it a member of a workgroup, instead of a domain. Since Enterprise CAs need to be joined to an AD DS domain,
do not attempt to install an offline CA as a Windows Server Enterprise CA.
The following checklists are to provide assistance in creating a CA hierarchy with an offline root CA and online subordinate CA.
Plan the renewal strategy you are going to use for the root certification authority.
Ensure that you publish the new CA certificate after it has been renewed.
On the new root CA, change the URL location of the certificate revocation list (CRL) distribution point to a location of your choice that is accessible to all users in you organization's network.
You may enter multiple URLs, which may be necessary if delta CRLs are enabled (not recommended for a root CA) or if there was a CA certificate renewal with a new key.
On the new root CA, change the URL location of the authority information access (AIA) distribution points to a location of your choice that is accessible to all users in you organization's network.
You may enter multiple URLs.
In Windows Explorer on the root CA, locate the certificate revocation list you just published. The CRL's default location is:%systemroot%\system32\CertSrv\CertEnroll\<CAname>.crl. Right-click the CRL file
and send it to a drive that has portable storage media.
Publish the root certificate to the enterprise root store and add the certificate to the customary Authority Information Access (AIA) points in the directory. You need to use certutil.exe. You can also use this command to put the CA certificate from a third
party root CA into Active Directory.
certutil -dspublish -f <FileName>.crt <RootCA>
Publish the CRL to the customary location in Active Directory. To do this, use certutil.exe. You can also use this command to put the CRL from a third-party root CA into Active Directory.
certutil -dspublish -f.<filename>.crl
There are several considerations related to building an offline root CA. The following sections link to additional information related to PKI design, offline root CA installation, and frequently asked questions (FAQ).