If you’re getting certificates for your Exchange 2007/2010 lab, you should use use the New-ExchangeCertificate cmdlet for 2007 or 2010. In 2010 there’s a Exchange Certificate Wizard that will make your life much easier. And if that’s not enough, Digicert has created a great webtool for it.
But if you, like me, really wanted to figure our what’s going on in the background, you can use the certreq.exe utility supplied since Windows 2000. It’s not as easy and to be honest, I don’t really know exactly what’s going on at all times, but I succeeded and this it how I did it…
When would you need this? Probably never since you have the options above, but I wanted to create a Certificate Request (CSR) and install a certificate with SAN (Subject Alternativ Name) on my stand-alone machine TMG1 running Microsoft Threat Management Gateway in my lab.
Oh and by the way, I use StartSSL who provide 1-year SSL-certificates for free and their root CA is installed on Windows by default. They don’t provide SAN-certificates tough.
There are 3 steps:
- Create a Certificate Request (CSR) on the server where the certificate will be installed
- Submit the CSR to the CA-server
- Install the certificate on the server
NOTE: We will be issuing a certificate with SAN, Subject Alternate Name so the CA-server has to be able to issue it. My CA was able to issue it using the New-ExchangeCertificate cmdlet, but when I did it with certreq.exe, the Subject Alternative Name value was simply missing:
I had to enable it on the CA-server.
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Restart the service. After that, the certificate contained the SAN.
Step 1:
Keep all files in a dir, for example C:\Temp. Create a file, csr.inf containing the following (make sure to replace sysadminlab.net with your domain).
[NewRequest]
Subject=”CN=owa.sysadminlab.net,OU=IT,O=Sysadmin Lab,L=Stockholm,S=Stockholm,C=SE”
Exportable=TRUE
KeyLength=2048
MachineKeySet=TRUE
FriendlyName=”Microsoft Exchange”
KeySpec=1
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
[RequestAttributes]
CertificateTemplate=WebServer
SAN=”dns=webmail.sysadminlab.net&dns=autodiscover.sysadminlab.net”
I don’t know if OID is really needed since it seems to be default if I remove it. Also, at first I got “Incorrect key type” when trying to choose the certificate in the TMG/ISA-server. Then I found this post describing KeySpec (which by default is 2 according to the certreq syntax). After adding that, it worked.
Anyway, with command prompt, run the command to create a new CSR and save it to request.req:
certreq -new csr.inf request.req
It will complain there’s no template called WebServer but that’s OK. It seems like you must supply a template name when requesting a certificate to Microsoft CA, otherwise you’ll get an error message.
Step 2:
Transfer request.req to the CA-server in some way. With the CA MMC-console, right-click your CA and choose All Tasks -> Submit new request… After a few seconds ask you were to save the certificate as a .cer-file. After saving it as certificate.cer, you can refresh the CA management console -> Issued Certificates and you will see the new certificate.
Step 3:
Transfer the certificate.cer file to the server and run the following command:
certreq -Accept certificate.cer
It won’t give you anything back but if you check the certificates MMC, you will see the certificate has been installed and has a private key and has the SAN field added:
If you’re like me and now have the certificate installed on a TMG/ISA server, you might want to change certificate on a web listener, do the following:
- Open Forefront TMG Management
- Task Pane to the right -> Toolbox -> Network Object -> Web Listeners
- Select the web listener -> Properties -> Certificates tab and select the certificate you want
I did a lot of requests and never installed all certificates. You might want to delete the pending request on the server. You’ll find them in the Certificates MMC -> Certificate Enrollment Requests.
Hi Jonas,
The OID (object identifier) identifies the permitted certificate key usage. For example a certificate than can be used for server authentication includes an OID of 1.3.6.1.5.5.7.3.1.
Depending on how the certificate will be used, the OID is usually defined by the relevant certificate template.
Cheers
JJ
“Transfer request.req to the CA-server in some way.” ????????!! What do you mean “IN SOME WAY”????
You can copy it over the network to UNC-path or map the CA-server’s C: drive using \\CASERVER\C$ or you could copy it manually to a USB-drive etc.