How To Request Certificate Without Using IIS or Exchange

The blog post on how to integrate Office 365 with Windows 2012 R2 AD FS raised an interesting question from a reader (Hi Eric!) on how should he request a certificate for the AD FS instance since there is no longer an IIS dependency.  This means that there is no longer an IIS console to generate a certificate request with.  What to do?

You could generate a certificate request, complete it and then export it to a .pfx file on an Exchange server.  The exported certificate can then be copied over to the AD FS server[s] and then imported to the local computer certificate store to make it available for AD FS purposes.

What if you don’t want, or can’t do this?  If you want to do this on the AD FS server directly then certreq.exe can help us out here!  This also applies to other servers and the application of the steps here are not just for AD FS.  However the question raised means that more folks in the field are probably thinking about the same thing, so that forced me to polish off yet another one of those draft blog posts!

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.

This post is using a venerable utility that has been present in Windows for a long time.  In a future post we can then look at the new features in PowerShell for this task.

Examining Certreq

Certreq.exe  is built into the underlying OS.  In the examples below we will use a Windows 2008 R2 SP1 server.  To see the options execute “certreq.exe /?”  This is shown in the image below, and the full command line parameters are at the bottom of this post for reference:

 

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 don’t want a SAN certificate, also called a Unified Communications certificate by various vendors, then simply comment out that line in the process below.

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

• sts.tailspintoys.ca

Along with the Subject Alternative Names of:

• legacy.tailspintoys.ca
• zorg.tailspintoys.ca

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.

Let’s go get crazy and request us some certificate!  *

Generate certificate request

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 we are locked on the names, then we can create the .inf file that we will feed to certreq.exe – there is a sample below for Windows 2008 and up.  Copy the content between the lines to the server, save it as policy.inf and then open it up in Notepad.

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

[Version]

Signature="$Windows NT$"

[NewRequest]

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.

;If you are using another protocol, verify the certificate requirements.

;EncipherOnly = FALSE ; Only for Windows Server 2003 and Windows XP. Remove for all other client operating system versions.

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]

; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7

; 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.

2.5.29.17 = "{text}"

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

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

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

; If your client operating system is Windows Server 2003, Windows Server 2003 R2, or Windows XP

; SANs can be included in the Extensions section only by adding Base64-encoded text containing the alternative names in ASN.1 format.

; Use the provided script MakeSanExt.vbs to generate a SAN extension in this format.

; RMILNE – the below line is remm'd out else we get an error since there are duplicate sections for OID 2.5.29.17

; 2.5.29.17=MCaCEnd3dzAxLmZhYnJpa2FtLmNvbYIQd3d3LmZhYnJpa2FtLmNvbQ

[RequestAttributes]

; If your client operating system is Windows Server 2003, Windows Server 2003 R2, or Windows XP

; and you are using a standalone CA, SANs can be included in the RequestAttributes

; section by using the following text format.

;”SAN="dns=not.server2008r2.com&dns=stillnot.server2008r2.com&dns=meh.2003server.com"

; Multiple alternative names must be separated by an ampersand (&).

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 =============================

Please Note: In the above sample, the lines that you will typically modify for Windows 2008 and  up are highlighted.  Also noted that in the SAN line there are no spaces between the FQDNs and the ampersand symbol is the separator.  Since we are using Windows 2008 R2 the SAN entries are placed in the [Extensions] section.  If we were running this on a Server 2003 box then we would use the [RequestAttributes] section or encode the SAN names using MakeSanExt.vbs.

Save this file with a .inf extension.  In this post we will call it policy.inf   The below shows the file in the C:\Certs folder.  Note the elevated cmd prompt!

Now that we have the required .inf file in place we can then create the certificate request:

Certreq.exe -New policy.inf newcert.req

This will generate the certificate, and in the folder there is now a file called newcert.req that we can provide to the issuing CA.

The newcert.req contains the public key of the certificate we just created – the private key does not leave the server.  You can see this certificate in the certificate MMC under Pending Enrolment Requests

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 and that it does not chain to an issuing CA.

And if we review the Details tab, the SAN entries are filled in:

Obtain response from issuing CA

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

Once the request process was followed, the response file was copied into the C:\Certs folder on the same server.

Update 12-5-2017:  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.

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:

certreq.exe -accept certnew.cer

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!

Potential Issues

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. 0
x800b010a (-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.

Use The Correct SAN Section Depending On The OS

If you use the default .inf file then chances are you will experience the lovely error below then pull some hairs out wondering where the issue lies.

The entry already exists.  0x800706e0 (WIN32: 1760)  <inf file name> [Extensions] 2.5.29.17 =

The sample .inf file includes multiple SAN sections and just like Highlander – there can be only one!  In the example provided in this post note that all of the lines in this section are remmed out.  The issue is with the highlighted line as it is not remmed out in the sample.  This then conflicts with the previous 2.5.29.17 section.

; If your client operating system is Windows Server 2003, Windows Server 2003 R2, or Windows XP

; SANs can be included in the Extensions section only by adding Base64-encoded text containing the alternative names in ASN.1 format.

; Use the provided script MakeSanExt.vbs to generate a SAN extension in this format.

; 2.5.29.17=MCaCEnd3dzAxLmZhYnJpa2FtLmNvbYIQd3d3LmZhYnJpa2FtLmNvbQ

Note the semi-colon at the start of the highlighted line above so that we do not conflict with the initial 2.5.29.17 section.

 

If you are trying to generate a SAN certificate on Windows 2008 R2, but the SAN fields are disappearing and only the common name entry remains when you provide the certificate request to the CA vendor then please check that you are specifying the SAN names in the right section.

Windows 2003 servers – place SAN names in the [RequestAttributes] section.  The sample line is commented out above as we are using Server 2008 R2.  Un-comment it and then place you SAN names here, and then comment out the 2.5.29.17  section.  In the sample I added the follow names to convey that 2008 does not use this section.

”SAN="dns=not.server2008r2.com&dns=stillnot.server2008r2.com&dns=meh.2003server.com"

Edit this to reflect correct values.  For example:

”SAN="dns=sts.tailspintoys.ca&dns=legacy.tailspintoys.ca&dns=zorg.tailspintoys.ca"

Windows 2008 / 2008 R2 servers – place the SAN names in the [Extensions] section using the 2.5.29.17 field.  Do not place them in the [RequestAttributes] section. Else quite simply this will no workey workey!

Certreq INF File Reference

Please refer to the documentation on TechNet.

Certreq Command Line Options For Reference

The  below certreq.exe  options are from a Windows 2008 R2 SP1 server:

Usage:
CertReq -?
CertReq [-v] -?
CertReq [-Command] -?

  CertReq [-Submit] [Options] [RequestFileIn [CertFileOut [CertChainFileOut [FullResponseFileOut]]]]

    Submit a request to a Certification Authority.

  Options:
-attrib AttributeString
-binary
-PolicyServer PolicyServer
-config ConfigString
-Anonymous
-Kerberos
-ClientCertificate ClientCertId
-UserName UserName
-p Password
-crl
-rpc
-AdminForceMachine
-RenewOnBehalfOf

  CertReq -Retrieve [Options] RequestId [CertFileOut [CertChainFileOut [FullResponseFileOut]]]
Retrieve a response to a previous request from a Certification Authority.

  Options:
-binary
-PolicyServer PolicyServer
-config ConfigString
-Anonymous
-Kerberos
-ClientCertificate ClientCertId
-UserName UserName
-p Password
-crl
-rpc
-AdminForceMachine

  CertReq -New [Options] [PolicyFileIn [RequestFileOut]]
Create a new request as directed by PolicyFileIn

  Options:
-attrib AttributeString
-binary
-cert CertId
-PolicyServer PolicyServer
-config ConfigString
-Anonymous
-Kerberos
-ClientCertificate ClientCertId
-UserName UserName
-p Password
-user
-machine
-xchg ExchangeCertFile

  CertReq -Accept [Options] [CertChainFileIn | FullResponseFileIn | CertFileIn]
Accept and install a response to a previous new request.

  Options:
-user
-machine

  CertReq -Policy [Options] [RequestFileIn [PolicyFileIn [RequestFileOut [PKCS10FileOut]]]]
Construct a cross certification or qualified subordination request
from an existing CA certificate or from an existing request.

  Options:
-attrib AttributeString
-binary
-cert CertId
-PolicyServer PolicyServer
-Anonymous
-Kerberos
-ClientCertificate ClientCertId
-UserName UserName
-p Password
-noEKU
-AlternateSignatureAlgorithm
-HashAlgorithm HashAlgorithm

  CertReq -Sign [Options] [RequestFileIn [RequestFileOut]]
Sign a certificate request with an enrollment agent or qualified
subordination signing certificate.

  Options:
-binary
-cert CertId
-PolicyServer PolicyServer
-Anonymous
-Kerberos
-ClientCertificate ClientCertId
-UserName UserName
-p Password
-crl
-noEKU
-HashAlgorithm HashAlgorithm

  CertReq -Enroll [Options] TemplateName
CertReq -Enroll -cert CertId [Options] Renew [ReuseKeys]
Enroll for or renew a certificate.

  Options:
-PolicyServer PolicyServer
-user
-machine

Cheers,

Rhoderick

* – I was led to believe that this was correct US grammar