How To Request Certificate Without Using IIS or Exchange–Updated 2022

Back in the year 2014 the post How To Request Certificate Without Using IIS or Exchange was released to help create TLS certificates. One of the main use cases was Active Directory Federation Services (AD FS) as in 2014 it was pretty much a requirement for enterprise migration to Office 365.  Password Hash Sync (PHS) and Pass Through Authentication (PTA) were still a twinkle in a developer’s eye….

If you wanted SSO, then Federation was your only option back then.  So we needed a mechanism to generate the TLS certificate for the AD FS environment.  AD FS 2012 R2 removed the IIS dependency so you could not manage the request using IIS Manager locally.  Additionally, Windows Server 2003 and 2008 were still supported and their options were also listed in the sample .inf file from the 2014 post.  Now that those platforms are out of support, those settings can be removed to streamline the .inf file.  Will also add a sample INF file to generate wildcard certificate to help with this issue.  More on the .inf files and their purpose shortly.

The intent is that the certificate will be issued by an external 3rd party CA, so that the certificate will be trusted and is valid for use on the Internet.  Internal Windows CAs are generally not much use when it comes to external clients and services as the certificate is typically not trusted automatically.  You can certainly request and issue the certificate from a properly configured Windows CA, and that can be very useful in a lab environment.

To manage the certificate request process outside of Exchange and IIS we will make use of the venerable windows utility certreq.exe.  Certreq.exe  is built into the underlying OS.  In the examples below we will use a Windows 2019 server.  To see the options execute “certreq.exe /?”   - the full command line parameters are documented here.

The goal of this exercise is to generate a certificate that will contain multiple Subject Alternative Names (SAN) in addition to the subject name (common name) of the certificate.  If you only want a single name, they remove the other SAN entry/entries leaving a single one present.  Certificates for secure web sites will need at least one SAN entry.

Before we can generate the certificate request we must be absolutely sure that we know the exact names that we want to include.  Once the certificate has been issued by the CA, it cannot be changed.  Some 3rd party CAs will charge a nominal amount to re-issue with a different/additional name, some will charge for a net new certificate. It is always best to do it right – the first time around!

Once the names are locked down, then we can create the .inf file that we will feed to certreq.exe.

For your certificate generation pleasure, two template files are included below.  You will see:

1. SAN Template
2. Wildcard Template

Select the one that best matches your requirements.  They are very similar and the same premise is used in both.  The actual content for each .inf file is between these sections:

========================== Copy all below this line =============================

The magic sauce goes in this area and that is what you need to copy.  Do NOT include the copy all below/above lines. 

========================== Copy all above this line =============================

Copy the content between these sections to your server, save it as YourPoilcyFileNameGoesHere.inf   - be sure to save as ANSI encoded  text file using Notepad. The encoding option is visible when you save the first time or a “Save As”.  Then edit to add/replace names as required as per your requirements.

You will want to review these lines:

• FriendlyName
• Subject
• Each SAN entry in the [Extensions] section
• CertificateTemplate

Once you have created your .inf file then we can proceed to generate the certificate.  Please ensure you saved as ANSI and the file extension is .inf to help minimise issues.

SAN Template

This section is the base template for a regular SAN certificate.  Instructions are noted earlier in this post.

========================== Copy all below this line =============================

[Version]
Signature="$Windows NT$"

[NewRequest]
FriendlyName = "Tailspintoys SAN Certificate"  ; Edit the friendly name.

Subject = "CN=sts.tailspintoys.ca" ; Remove to use an empty Subject name.

;TLS does not require a Subject name.  SAN extension to be used as per RFC2818. The certificate Subject name can be empty.

Exportable = TRUE ; TRUE = Private key is exportable

KeyLength = 2048 ; Valid key sizes: 1024, 2048, 4096, 8192, 16384

KeySpec = 1 ; Key Exchange – Required for encryption

KeyUsage = 0xA0 ; Digital Signature, Key Encipherment

MachineKeySet = True

ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

RequestType = PKCS10 ; or CMC.

[EnhancedKeyUsageExtension]
; If you are using an Enterprise CA the EnhancedKeyUsageExtension section can be omitted

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

[Extensions]
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
; Three SAN entries are listed below for the STS, EnterprseRegistration and Zorg FQDNs

2.5.29.17 = "{text}"

_continue_ = "dns=sts.tailspintoys.ca&"

_continue_ = "dns=enterpriseregistration.tailspintoys.ca&"

_continue_ = "dns=zorg.tailspintoys.ca&"

[RequestAttributes]
CertificateTemplate = WebServer ; Modify for your environment by using the LDAP common name of the template.
;Required only for Windows Enterprise CAs.

========================== Copy all above this line =============================

Wildcard Template

This section is the base template for a wildcard certificate.  Note that it is still basically a SAN certificate.  The *.tailspintoys.ca and tailspintoys.ca names are entered in the SAN field.  The subject or common name field is not longer used by modern browsers.    Instructions are noted earlier in this post.

========================== Copy all below this line =============================

[Version]
Signature="$Windows NT$"

[NewRequest]
FriendlyName = "Tailspintoys Wildcard Certificate"  ; Edit the friendly name.

Subject = "CN=*.tailspintoys.ca" ; Remove to use an empty Subject name.

;TLS does not require a Subject name.  SAN extension to be used as per RFC2818. The certificate Subject name can be empty.

Exportable = TRUE ; TRUE = Private key is exportable

KeyLength = 2048 ; Valid key sizes: 1024, 2048, 4096, 8192, 16384

KeySpec = 1 ; Key Exchange – Required for encryption

KeyUsage = 0xA0 ; Digital Signature, Key Encipherment

MachineKeySet = True

ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

RequestType = PKCS10 ; or CMC.

[EnhancedKeyUsageExtension]
; If you are using an enterprise CA the EnhancedKeyUsageExtension section can be omitted

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

[Extensions]
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
; Two SAN entries are listed below for the wildcard namespace of *.tailspintoys.ca and also for the domain itself.

2.5.29.17 = "{text}"

_continue_ = "dns=*.tailspintoys.ca&"

_continue_ = "dns=tailspintoys.ca&"

[RequestAttributes]
CertificateTemplate = WebServer ; Modify for your environment by using the LDAP common name of the template.
;Required only for enterprise CAs.

========================== Copy all above this line =============================

Process Overview

We can break this down into three basic steps:

1. Generate certificate request

2. Obtain response from issuing CA

3. Import response to complete certificate

The syntax is to use certreq.exe with the –New parameter  and specifying the request file that we can take to the issuing CA.   Once the signed CA response has been obtained and copied back to the server, we can then import it using the –Accept parameter to complete the certificate request process.

Generate certificate request

This step requires that the .inf file has been prepared.  If that has not yet been done, scroll back up and read that section.  In this example we will use the SAN certificate template.  We will generate a certificate that will contain multiple Subject Alternative Names (SAN) in addition to the subject name (common name) of the certificate.

We want to end up with a  certificate that has the following Subject name:

• sts.tailspintoys.ca

Along with the Subject Alternative Names of:

• sts.tailspintoys.ca

• enterpriseregistration.tailspintoys.ca

• zorg.tailspintoys.ca

In this example the template was saved to folder C:\Certs\2022\SAN\ with a file name of Updated-SAN.inf.  Note that it was saved using ANSI encoding.

In an elevated prompt we ran:

Certreq.exe -New Updated-SAN.inf CertNew.req

This will generate the certificate within the local machine store.

The output file, CertNew.req contains the certificate’s public key which we will need to get signed by the issuing CA.  This is all standard Certificate Signing Request (CSR) activities.

For your viewing pleasure, the this is a text encoded file that we can easily open with notepad.  When submitting to the CA include *ALL* the content of the file.  Including the

----BEGIN NEW CERTIFICATE REQUEST----  and ----END NEW CERTIFICATE REQUEST----  lines.

The Certnew.req contains the public key of the certificate we just created – the private key does not leave the server.  You can see this certificate and the fact that it has a private key in the certificate MMC under Certificate Enrolment Requests.

For a quick shortcut to open the local computer certificate MMC please see this post.

If you look at the properties of the certificate, in the Certificate Enrolment Requests folder, note that:

• The private key is present
• The certificate is not trusted
• It does not chain to an issuing CA

A summary of some of the properties are shown below whilst the certificate is in the pending state.

Note that the SAN entries are present (as we supplied them in the request), but the certificate is not trusted and does not chain to an issuing CA.

 

Obtain response from issuing CA

In this step the Certnew.req was provided to the CA. For external facing AD FS certificates you will need to go and follow the process with your chosen 3rd party CA.  The choice is all yours!

Once the request process was followed, the response was copied into the  folder on the same server.  You may get a single file, a ZIP or a series of files.

Please review and follow the steps and guidance provided by the issuing CA.  You may need to do additional steps such as update intermediate CA certificates etc.  The steps will change over time, and also by vendor.

Note that this post is intended for Exchange/AD FS Internet facing purposes so that the certificate is issued by an external 3rd party CA.  That is why an internal CA is not mentioned.  If you do want to use this process to obtain the certificate from an internal Windows CA then the request can be submitted to the CA using the certreq.exe -submit  command or via the enrollment web site.

Import Response To Complete Certificate

Once we have obtained the signed response from the issuing CA, copy it to the server.  Then we can mate the pending certificate request with the signed CA response.  In this example the signed response file was saved locally to the same folder with file name of CAResponse.cer  - note that this will be different for you so please adjust accordingly.

certreq.exe -Accept CAResponse.cer

Windows recognises that this is the signed CA response to a pending certificate request.  As you can see above, the request process is completed and certutil returns some of the certificate’s properties to the screen for confirmation.

Please ensure that all of the documentation from your CA provider has been followed.  There might be steps to remove built-in certificates from Windows, modify their purpose to add brand new intermediate CA certificates.  This changes vendor by vendor, where it was issue from and over time.  Please follow their instructions for the most up-to date information!

The certificate request has been completed, so it is no longer visible under pending requests in the certificate MMC.  Refresh the LocalMachine\Personal\Certificates store and the certificate should be visible there.  In this example  note that the certificate is now trusted and reflects the policy of the issuing CA.  For example you may note that the valid From/Valid to is different, as is the hash algorithm.

Potential Issues

Some potential issues which may arise.

CSR Decoder

There are multiple CSR decoding tools available on the Internet.  Either use the decoder created by your CA vendor, or have a search.

Microsoft Documentation

Microsoft Docs lists all of the certreq.exe options for reference here.

File Not ANSI Encoded

Even on a Windows Server 2019 system, when the .inf was saved as UTF-8, certutil errored out.  Simplest solution was to do a Save As in Notepad, and save using ANSI.

Certificate Request Processor: Expected INF file section name 0xe0000000 (INF: -536870912)
UpdatedSAN2.inf

Update Intermediate CA Certificates

If the necessary CA certificates have not been updated as per the CA documentation you may receive the below:

Certificate Request Processor: A certificate chain could not be built to a trusted root authority. 0x800b010a (-2146762486)

Please follow the provided documentation to import the necessary certificates etc. that was provided to you by the CA and then re-attempt the import.

Cheers,
Rhoderick