From Linux to Windows: Migrating Your Certificate Authority
PKI Migration • Certificate Management • Enterprise CA
Move your existing OpenSSL-based Certificate Authority to Windows Server for centralized management, web enrollment, and proper certificate revocation.
Why Move to Windows CA?
Many of us are always installing and testing new software, trying to secure everything properly. The problem is that using OpenSSL every single time takes too much time. Windows Server’s Certificate Services provides a web interface and proper revocation infrastructure while preserving your existing root CA.
Migration Process
Root CA Setup
If you have a working root CA, just convert it to PFX format for Windows import. If not, create one first.
# If you don't have a root CA, create one:
openssl genrsa -out rootca.key 4096
openssl req -new -x509 -days 3650 -key rootca.key -out rootca.crt -sha256
# Convert existing/new root CA to PFX format
openssl pkcs12 -export -out rootca.pfx -inkey rootca.key -in rootca.crtImport and Configure Windows CA
Import to Personal store, install Certificate Services role, and select “Use existing certificate” during configuration.
# Import PFX to Personal certificate store
Import-PfxCertificate -FilePath "C:\path\to\rootca.pfx" -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -String "YourPassword" -AsPlainText -Force)Install Certificate Services Role
Install Active Directory Certificate Services role, select “Use existing certificate” during configuration, and enable web enrollment.
# Install CA role and web enrollment
Install-WindowsFeature ADCS-Cert-Authority, ADCS-Web-Enrollment -IncludeManagementTools
# Run CA configuration wizard (GUI) or use PowerShell:
# - Select "Use existing certificate"
# - Choose your imported certificate
# - Enable web enrollment featureOnce configured, you can access the web interface at https://your-server/certsrv to submit CSRs and download certificates.
Improved Certificate Workflow
Instead of manually crafting OpenSSL commands, use standardized configuration templates and submit CSRs through the web interface.
Script the CSR Generation
Instead of manually creating OpenSSL configs every time, use a script. Here’s what a typical config file looks like:
# server.cnf - OpenSSL configuration file
[ req ]
default_bits = 2048
default_md = sha256
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C = US
ST = State
L = City
O = Company
OU = IT
CN = server.domain.local
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment, nonRepudiation
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = server.domain.local
IP.1 = 192.168.1.100Automate Configuration Generation
Creating this file manually every time is tedious. Here’s a script that generates it automatically:
#!/bin/bash
# Usage: ./gen-csr.sh hostname IP
if [ "$#" -ne 2 ]; then
echo "Usage: $0 "
exit 1
fi
HOSTNAME=$1
IP=$2
KEY_FILE="${HOSTNAME}-key.pem"
CSR_FILE="${HOSTNAME}.csr"
CONF_FILE="${HOSTNAME}.cnf"
# Create OpenSSL config
cat > "$CONF_FILE" < Now you can generate CSRs in seconds, submit them through /certsrv, download the signed certificate, and deploy both the key and certificate to your services.
Key Benefits
Web Interface
Submit CSRs and download certificates through /certsrv without shell access.
Proper Revocation
Built-in CRL distribution and OCSP responder for certificate validation.
Certificate Templates
Standardized certificate policies and automated approval workflows.
Making the Switch
Migrating to Windows Certificate Services transforms manual certificate operations into standardized workflows. Your existing infrastructure continues working unchanged, but now with enterprise-grade certificate lifecycle management.
The investment in setup pays dividends in operational efficiency, especially when managing certificates across multiple services and environments.
