- Tactical RMM: Open Source remote monitoring and management for Windows - Thu, Jan 27 2022
- Use OpenSSL-based software XCA as offline root certificate authority for AD Certificate Services - Wed, Jan 27 2021
- Deploy software with WPKG and Active Directory - Tue, Dec 8 2020
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.
Consider the deployment scenario depicted below:
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.
Then create a new certificate. This will be the root CA certificate:
- Signing: Create a self-signed certificate
- Signature algorithm: SHA256
- Template for the new certificate: [default] CA, then click Apply All
- 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
- 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).
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.
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.
Import the certificate signing request and create the certificate
In XCA, go to the Certificate Signing Requests tab and import the CSR file.
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.
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.
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.
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
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.