When Active Directory Certificate Services are deployed, Microsoft recommends at least a two-tier infrastructure, comprising a root CA and a subordinate CA. For security reasons, it's recommended to keep the root CA offline. Since the root CA is used only for signing the intermediate CA certificates, many sysadmins don't like the idea of burning a Windows license for a powered-off server. A convenient solution is to use a non-MS offline CA.
Avatar
Create the CRL

Create the CRL

In this article, we are going to create our offline CA with XCA, a standalone program made for easily managing a full-blown Certificate Authority, which is wrapped on OpenSSL. With this solution, you could work with the CA with your admin workstation and leave the CA database offline, for example, on a USB thumb drive kept in secure storage.

You can download the latest version of XCA via its release page on GitHub.

Deployment Scenario

Consider the deployment scenario depicted below:

CA hierarchy

CA hierarchy

Create the root CA certificate

Launch XCA and create a new database. As the first security measure, set a strong password for private key encryption in the database.

Create new XCA Database

Create new XCA Database

Then create a new certificate. This will be the root CA certificate:

Source tab

  • Signing: Create a self-signed certificate
  • Signature algorithm: SHA256
  • Template for the new certificate: [default] CA, then click Apply All

Subject tab

  • Distinguished name: Fill in the distinguished name details according to your environment
  • Private key: Click the Generate a new key button and generate an RSA 2048 bit key
Fill in the certificate details

Fill in the certificate details

Extensions tab

  • X509v3 basic constraints: Set path length to 1. This means that subordinate CAs cannot sign other CA certificates
  • Validity: Set time range to at least 10 years and click Apply

Leave the defaults on the other tabs and click OK.

Once you have created the CA certificate, create the certificate revocation list. Go to the Revocation Lists tab and create a new revocation list. Set your desired validity (I suggest at least one year).

Create the CRL

Create the CRL

Then export the CA certificate and the CRL. Export them both in PEM (*.crt) format. The CRL file must follow the naming of CRL distribution points defined later in AD CS. In this case, the CRL file is exported as LAB AD CA.crl.

Deploy the CA certificate with Group Policy

Create a new GPO and link it at the domain level. In Policies\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities, import the previously exported root CA certificate.

Deploy the CA certificate via GPO

Deploy the CA certificate via GPO

Configure Active Directory Certificate Services

Install AD CS and generate the CSR

Let's move on to the server designated to act as the certificate authority. Open Server Manager and add the Active Directory Certificate Services Role.

Once the role is added, complete the configuration wizard:

  • Setup Type: Select "Enterprise CA"
  • CA Type: Select "Subordinate CA"
  • Private key: Create a new private key
  • Certificate Request: Select "Save the certificate request."

Once you have completed the wizard, pick the certificate signing request file and import it to XCA.

AD CS configuration summary

AD CS configuration summary

Import the certificate signing request and create the certificate

In XCA, go to the Certificate Signing Requests tab and import the CSR file.

Import CSR into XCA

Import CSR into XCA

Once the CSR is imported, right-click the CSR entry and select Sign. Make sure you have selected your root CA for signing and click OK.

CSR is signed and the sub CA certificate is ready

CSR is signed and the sub CA certificate is ready

Next, go to the Certificates tab and export the newly created certificate in PEM (*.crt) format.

Install the certificate on AD CS

Move to the AD CS server.

Copy the previously exported CRL file to C:\Windows\System32\CertSrv\CertEnroll.

Open the Certification Authority snap-in and install the just exported CA certificate.

Install the CA certificate

Install the CA certificate

Once the CA certificate is installed, you can start the service, and the setup is complete.

When you activate the auto enrollment policies, you should see certificates being issued to your servers.

Troubleshooting

During certificate enrollment, you may encounter errors related to the revocation function:

The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

This is often related to a CRL misplacement or means the CRL validity period has expired.

A possible workaround is to temporarily disable the offline check of CRL:

certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

Final thoughts

When small organizations are tight on budget and cannot afford the costs of an enterprise CA infrastructure, or IT infrastructure is so small that an enterprise offline root CA isn't justifiable, XCA comes in handy. If properly used, the PKI could be maintained reasonably securely.

6 Comments
  1. Avatar
    Midar 3 years ago

    So XCA can be installed directly on DC, where AD CS also runs? (small company, only two DC)

  2. Avatar Author

    Yes, you can keep it on the DC. You don’t need to install XCA since it’s portable. If you are running a virtual environment it is convenient to create a detachable hard drive which you can use to keep XCA and its database on it.

  3. Avatar
    Daniel 3 years ago

    One thing you've left out which is fairly important is setting the X509v3 CRL Distribution Points extension when signing the issuing CA certificate. Having this point to a valid URL where the Root CA CRL is available will avoid the 80092013 error and having to disable CRL checking.

    If the CA Web Enrollment role is installed on the CA there will already be an IIS Virtual Directory pointing to C:\Windows\System32\certsrv\CertEnroll where we've copied the CRL file. The CRL CDP path will be in the format of URI:http://<Issuing CA Server>/CertEnroll/<CRL File> (e.g. "http://SV01.lab.local/CertEnroll/LAB AD CA.crl"). The CRL CDP should point to the CRL for the CA that issued the certificate, so the issuing CA's CDP should be the CRL of the root CA.

    You can then validate that the CRL is available with:

    certutil -URL "http://SV01.lab.local/CertEnroll/LAB AD CA.crl"

    And then validate the certificate chain and CRL:

    certutil -f –urlfetch -verify <Certificate File>

    With this step added before importing the issuing CA certificate you will have a completely valid PKI infrastructure with working CRL validation.

    • Avatar
      Radim 3 years ago

      Hi.

      Unfortunately, my Enterprise CA (generated with XCA) probably does not contain the X509v3 CRL Distribution Points extension and therefore my PKI does not currently work 🙁
      Everywhere I see the error "Automatic certificate enrollment for local system failed (0x80092012) The revocation function was unable to check revocation for the certificate".
      I do not see any Issued Certificates in the mmc Certification Authority. But I have a lot of errors in Failed Request: "Request Disposition Message: Error Constructing or Publishing certificate" and same error as above (0x80092012) : – ((
      When using the command 'certutil -f –urlfetch -verify <Certificate File>' I see in the listing:
        —————- AIA Certificate —————-
         No URLs "None" Time: 0 (null)
         —————- Certificate CDP —————-
         No URLs "None" Time: 0 (null)
         —————- Certificate OCSP —————-
         No URLs "None" Time: 0 (null)
         ——————————–

      Can you help me please ? What should I do ?
      Thank you very much.

  4. Avatar Author

    You have to set the CRL distribution point in the CA certificate also, then put the CRL in your Web root of Web Enrollment.

     

  5. Avatar
    Radim 3 years ago

    Can you be more specific about how to do that, please ?

    Thanks a lot!

Leave a reply

Please enclose code in pre tags: <pre></pre>

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account