In many environments, operational certificates for web servers and services are still requested manually via MMC or the web enrollment pages. This PowerShell script automates that process by generating a certificate signing request (CSR), submitting it directly to a Microsoft Enterprise CA, and optionally exporting the issued certificate as a PFX file.
The script supports two modes:
- Import mode: Read subject and SAN information from an existing certificate in the local certificate store (for renewal or duplication).
- Manual mode: Build the subject and SAN list from manually specified values in the script.
In both cases, the script generates an INF file, calls certreq.exe to create and submit the CSR to a specified issuing CA using a specific certificate template, and finally installs the issued certificate and optionally exports it to PFX.
You can download the script from GitHub here:
Download the script on GitHub
Modes and main behavior
Import mode
In import mode, the script:
- Opens the configured certificate store (
$SourceStore, e.g.LocalMachine\My). - Prompts for a certificate serial number and looks up the certificate in that store.
- Parses the subject into its components (CN, O, OU, L, C, E) and extracts Subject Alternative Names (DNS and IP) from the SAN extension.
- Prompts interactively for any missing fields (e.g. if the original certificate did not contain OU or E).
This is ideal for renewing existing certificates with the same subject and SANs or cloning an existing certificate’s identity for another host.
Manual mode
In manual mode, all relevant subject fields and SANs are configured directly in the script:
$CommonName,$FriendlyName$Org,$OrgUnit,$City,$Country,$EMail$SANsas an array of DNS names/IP addresses
The script then constructs the subject DN from these values and builds the SAN extension accordingly (separating IP addresses and DNS names), without relying on an existing certificate.
Both modes then use the same logic for building the INF, submitting the CSR, and importing/exporting the resulting certificate.
Configuration variables and parameters
Mode & source
| Variable | Example value | Description |
|---|---|---|
$Mode | "import" / "manual" | Selects whether to read fields from an existing certificate or use manual input. |
$SourceStore | "LocalMachine\My" | Certificate store used in import mode, e.g. LocalMachine\My or LocalMachine\WebHosting. |
Manual subject and SAN configuration
(used when $Mode = "manual")
| Variable | Example value | Description |
|---|---|---|
$CommonName | "webserver.domain.tld" | Common Name (CN) of the certificate subject. |
$FriendlyName | $CommonName | Friendly name shown in the certificate store. |
$Org | "Company" | Organisation (O). |
$OrgUnit | "IT" | Organisational Unit (OU). |
$City | "New York" | Locality (L). |
$Country | "US" | Country (C), two-letter ISO code. |
$EMail | "system.owner@domain.tld" | E-mail (E) attribute in the subject. |
$SANs | @("webserver.domain.tld","other-url.domain.tld") | List of SAN entries (DNS names or IP addresses). |
CA, template and output
(these are required in both modes)
| Variable | Example value | Description |
|---|---|---|
$CAName | "Server.domain.tld\Company Issuing CA" | Full configuration string of the issuing CA used with certreq -config. |
$Template | "WebServerTemplate" | Name of the certificate template to be used for the request. |
$OutputBaseDir | "C:\Temp\CertRequest" | Base directory where INF, CSR, issued certificate and optional PFX are stored. |
The script creates a subfolder per Common Name under $OutputBaseDir, writes request.inf and request.req there, submits the CSR, and finally stores cert.cer and optionally the exported PFX in the same folder.
Determining the internal issuing CA name
The variable $CAName must match the internal configuration name of your issuing CA, not just a display string. There are several ways to find it:
- On a domain-joined machine with the AD CS tools, open a command prompt.
- Run:
certutil -config - -pingThis shows a list of available CAs in the formatServerName\CAName. Select the correct issuing CA from the list and copy the string exactly into$CAName. - Alternatively, on the CA server itself, open the Certification Authority MMC. The node in the left-hand tree (e.g.
Server.domain.tld\Company Issuing CA) is the same string you must use for$CAName.
Using the exact configuration string avoids certreq errors when submitting the CSR.
Determining the certificate template name (no spaces)
For the $Template variable, you must use the template name (has no spaces), not the display name.
- On a system with the certificate templates snap-in, open Certificate Templates (
certtmpl.msc). - Locate the template you want to use (for example, your web server or server authentication template).
- Right-click the template and open Properties. On the General tab you will see:
- Template display name – friendly name, can contain spaces (e.g.
Web Server SSL) - Template name – internal name, typically without spaces (e.g.
WebServerSSL)
- Template display name – friendly name, can contain spaces (e.g.
For scripting and certreq, use the Template name, and define it without spaces if possible.
If the current template name contains spaces, consider duplicating the template and assigning a new template name without spaces (for example, WebServerTemplate instead of Web Server Template). This avoids parsing issues and makes automation more robust.