다음을 통해 공유

Offline Root Certification Authority (CA)

  • 아티클

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.

 

CA Compromise

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

How Do Offline CAs issue certificates?

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.

 

↑ Return to Top

How Many Levels in the CA hierarchy?

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 and library.

 

↑ Return to Top

Do not join offline CAs to an Active Directory Domain Services domain

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.

 

↑ Return to Top

Checklists

The following checklists are to provide assistance in creating a CA hierarchy with an offline root CA and online subordinate CA. 

Installing an Offline Root CA Checklist

 

Complete? Item Notes and References
Ensure you understand the PKI basic concepts. Certificate Concepts
Plan the CA hierarchy. Certification authority hierarchies
Set up a server that runs Windows that you will use for the root certification authority. The server should not be a member of any domain, should be disconnected from the network, and should be physically secure. Checklist: Performing a new installation

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.

 Renewing a certification authority
Log on to the server as the administrator and install Certificate Services to create a stand-alone root certification authority. Install a stand-alone root certification authority
On the new root CA, change the default action upon receipt of a certificate request so that all requested certificates are set to pending. This is to ensure only authorized requests are issued by the top-level CA. Set the default action upon receipt of a certificate request

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.

 Specify certificate revocation list distribution points in issued certificates

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.

 Specify CA certificate access points in issued certificates
Configure the offline root certification authority to support certificate revocation with Active Directory. Configure an offline root certification authority to support certificate revocation with Active Directory 
On the root certification authority, publish the certificate revocation list. Manually publish the certificate revocation list

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.
Retrieve the certification authority's certificate and save it to a drive that has portable storage media. Retrieve a certification authority certificate
Copy the certificate revocation list file and the CA certificate to every URL location that you specified as a CRL distribution point in the root CA's policy settings.
Copy the CA certificate file to every URL location that you specified as an authority information access distribution point in the root CA's policy settings.

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>

 For Active Directory Domain Service (AD DS) environments

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

 For Active Directory Domain Service (AD DS) environments

 

↑ Return to Top

Installing an Online Subordinate CA to an Offline Root CA

 

Complete? Item Notes and References
 Set up a server running Windows to use for the subordinate certification authority  Checklist: Performing a new installation
 Install subordinate certification authorities, as required by your planned certification hierarchy. These can be stand-alone certification authorities or, if you are using Active Directory, enterprise certification authorities. During setup for each subordinate CA, choose to save the CA certificate request to a file, which will be a PKCS #10 request. Install a stand-alone subordinate certification authority; Install an enterprise subordinate certification authority
Copy the CA certificate request file from the subordinate certification authority to some portable storage media. Take the CA certificate request to the root certification authority.
Using the Certificates Microsoft Management Console (MMC) on the offline CA, submit the certificate request (requestfilename) to the CA and copy the new certificate (newcertname) to the portable storage media. Manage certificates for a computer
Take the portable storage media back to the subordinate certification authority. In Windows Explorer, locate the certificate and certification path files you just copied, then right-click each file and choose Install Certificate. Have the Certificate Import Wizard automatically place the certificates in stores based on the type of certificate. Import a certificate

 

↑ Return to Top

Additional Resources

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).

 

PKI Design

 

Offline Root CA Installation

 

FAQ: Offline Root CAs

 

↑ Return to Top