Alan's sysadmin Blog

Working smarter not harder

Archive for the ‘Certificates’ Category

Script: Checking for Expired Certificates in Exchange

Posted by Alan McBurney on August 27, 2014

I was working with a customer that had unintentionally let their Exchange certificates expire.

This resulted in a bit of a headache for the team as users were now getting certificate warnings and mobility services were down until the certificate was replaced.

I decided to put together a script that will check and warn about expired or soon to expire certificates.
The script gets the certificates which have services bound to them on all Exchange 2010 client access and hub transport servers.
It checks for certificates that have expired or that will expire within the next 60 days and optionally emails the report and creates a schedule task.
An email will only be generated if expired\expiring certificates have been detected

Detects expired certificates on Exchange 2010 Client Access & Hub Transport servers
Version 1.0, August 27th, 2014
This script will get the certificates which have services bound to them on all Exchange 2010
client access and hub transport servers.
It checks the expiration for any certificates that are due to expire within 60 days and optionally
emails the report and creates a schedule task
An email will only be generated if expired\expiring certificates have been detected
Parameters, checks and scheduled tasks stolen from Steve Goodman's Exchange Environmental Reports script
To Do list: Enable Autnetication for SMTP
Support for Exchange 2007 & 2013
Send Mail after completion. Set to $True to enable. If enabled, -MailFrom, -MailTo, -MailServer are mandatory
Email address to send from. Passed directly to Send-MailMessage as -From
Email address to send to. Passed directly to Send-MailMessage as -To
SMTP Mail server to attempt to send through. Passed directly to Send-MailMessage as -SmtpServer
Attempt to schedule the command just executed weekly. Specify the username here, schtasks (under the hood) will ask for a password later.
[parameter(Position=1,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Send Mail ($True/$False)')][bool]$SendMail=$false,
[parameter(Position=2,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Mail From')][string]$MailFrom,
[parameter(Position=3,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Mail To')]$MailTo,
[parameter(Position=4,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Mail Server')][string]$MailServer,
[parameter(Position=5,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Schedule as user')][string]$ScheduleAs
#Check Powershell Version
if ((Get-Host).Version.Major -eq 1)
  throw "Powershell Version 1 not supported";
#Check Exchange Management Shell, attempt to load
if (!(Get-Command Get-ExchangeServer -ErrorAction SilentlyContinue))
  if (Test-Path "C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1")
    .'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
    Connect-ExchangeServer -auto
  } elseif (Test-Path "C:\Program Files\Microsoft\Exchange Server\bin\Exchange.ps1") {
    Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.Admin
    .'C:\Program Files\Microsoft\Exchange Server\bin\Exchange.ps1'
    } else {
    throw "Exchange Management Shell cannot be loaded"
# Check if -SendMail parameter set and if so check -MailFrom, -MailTo and -MailServer are set
if ($SendMail)
  if (!$MailFrom -or !$MailTo -or !$MailServer)
    throw "If -SendMail specified, you must also specify -MailFrom, -MailTo and -MailServer"
$HTMLReport = $Dir + "\ExpiredCerts.html"
$CASServers = Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -match "Version 14" -and $_.ServerRole -match [regex] 'Hub|Client'}
$Certs = Foreach ($srv in $CASServers) {Get-ExchangeCertificate -Server $srv| Where-Object {$_.NotAfter -le (Get-Date).AddDays(60) -and $_.Services -ne "None"} | Select @{n="Server";e={$}}, @{n="Expiry Date";e={$_.NotAfter}}, Thumbprint, Services, Issuer, Subject}
$Certs | ConvertTo-Html | Out-File $HTMLReport

if ($SendMail)
  if ($Certs.count -gt 0)
    Send-MailMessage -Attachments $HTMLReport -To $MailTo -From $MailFrom -Subject "Warning - Expired Exchange Certificates Detected" -Body "Expired or soon to be expired certificates have been detected on Exchange Servers. Please see attached file for certificates affected" -SmtpServer $MailServer
if ($ScheduleAs)
  if ($SendMail)
    $params+=' -SendMail:$true'
    $params+=" -MailFrom:$MailFrom -MailTo:$MailTo -MailServer:$MailServer"
  $task = "powershell -c \""pushd $dir; $($myinvocation.mycommand.definition) $params\"""
  schtasks /Create /RU $ScheduleAs /RP /SC WEEKLY /ST 22:00 /TN ExpiredCerts /TR $task


Posted in Certificates, Exchange 2010, PowerShell, Windows 2008 R2, Windows Server 2012, Windows Servers | Tagged: , , | Leave a Comment »

Install Certificate Services on Server 2012 Core

Posted by Alan McBurney on July 24, 2013

I’m finally getting the time to focus more and more on Windows Server 2012.

With Server 2012 I’m running Domain Controllers as server core installations.

My reasoning for running DC’s using core is as follows:

  • No additional software can be installed on the server. Domain Controllers are Domain Controllers are Domain Controllers.
  • With server core installations admins generally don’t log onto the server unless they are comfortable with the command line and Shell and even then they only log on typically when something needs to be changed with the configuration.
  • Surface area is greatly reduced as there are limited binaries installed.
  • Memory is also minimal. My server core installs are running with 512MB RAM
  • Disk requirements are reduced

All of the above in my opinion leads to a more stable system.
On the downside though it takes a bit more work to get things up and running.

Getting Certificate Services up and running on the server core installation was pretty easy.

Once logged onto the server I run PowerShell from the cmd line and then Import-Module ServerManager


Next is to add the Active Directory Certificate Services & Certification Authority roles

Add-WindowsFeature AD-Certificate, ADCS-Cert-Authority

A reboot is required after installation.

After the comes has rebooted we can check that the features have been installed by running

Get-WindowsFeature | Where Installed


We now need to configure the Certificate Authority. To do this we need a bit of code that Microsoft has handily already provided here

Copy the code into notepad on the server core installation and save to a  location on the disk.
(I RDP to my server core installation and therefore can paste the clipboard contents from my desktop to the server core console.)

Final piece of the configuration is to run the SetupCA.vbs fiile using the following parameters

cscript SetupCA.vbs /IE


Once installed I can now manage the CA from any workstation or  server running RSAT.


Posted in Certificate Authority, Certificates, PowerShell, Server Core, Windows Server 2012 | Tagged: , , | 1 Comment »

Creating OpenSSL Certificates for vSphere & vCenter

Posted by Alan McBurney on October 28, 2011

I have been meaning to write this blog post for a while but never quite managed to find the time until now.

As part of a project that I have been working on, I had a need to replace the default certificates that get installed during the installation of vCenter and vSphere 4.1 with OpenSSL certificates.

This guide is based on vSphere & vCenter 4.1 although it should also work for vSphere 5

The process will be broken into a number of steps

  1. Installation of OpenSSL & creating the working directory structure
  2. Creating a Root CA
  3. Creating the CSRs (Certificate Signing Requests) for vSphere and vCenter
  4. Signing the CSRs using the Root CA
  5. Assign certificates to vCenter & vSphere
  6. Deploying the OpenSSL RootCA via GPO

I want to make this process as easy as possible and as such I’ll be using the default values that are already predefined in the openssl.cfg file

So lets get started with replacing vSphere certificates.

Installing OpenSSL & creating the directory structure

Download OpenSSL for Windows x64 from


Accept the license agreement and use the defaults when installing.

OpenSSL has now been installed to C:\OpenSSL

The next thing that needs to be done is to create the working directory structure. The directory structure will be used when signing the certificates using the RootCA.

Use the following commands

mkdir C:\openssl\bin\demoCA\newcerts
mkdir C:\OpenSSL\bin\demoCA\private
Copy C:\OpenSSL\bin\PEM\demoCA\serial C:\OpenSSL\bin\demoCA\
copy con C:\OpenSSL\bin\index.txt

(after issuing the above command use CTRL-Z then enter to finish the command. This will create a blank document called index.txt)


Creating the Root CA

We are now ready to create the RootCA.
Open a command prompt at C:\OpenSSL\bin and issue the below command

openssl req -new -x509 -extensions v3_ca -keyout rootca.key -out rootca.crt -days 3650 -config openssl.cfg

The first thing that you will be asked for is a “Enter PEM pass phrase:”

This is a pass phrase of your own choosing (Should be a strong pass phrase) and will be used again when signing the certificates for vSphere & vCenter

Complete the remainder of the fields that you are asked information about.
The relevant fields have been highlighted in the below graphic.


Once the command has complete you will find 2 new files named rootca.crt and rootca.key within C:\OpenSSL\bin


Creating the CSR’s

Next we need to create the CSRs for the vsphere and vcenter certificates

Again open a command prompt from C:\OpenSSL\bin and issue the following commands

openssl req -new -nodes -out vsphere.csr -keyout vsphere.key -config openssl.cfg

openssl req -new -nodes -out vcenter.csr -keyout vcenter.key -config openssl.cfg

The above commands will create the CSRs, each CSR will consist of 2 files, the csr file and the key file.

At the end of the request you will be prompted to enter ‘extra attributes’. Leave these 2 options blank.

The yellow highlight below are the options that you need to fill in, the green are the optional setting that are to be left blank.


We now have the private key and the CSR for both vsphere and vcenter within C:\OpenSSL\bin.


Signing CSR

The next step is issue certificates based on the the CSRs using the RootCA.

Remember back to that start when we created the directory structure? Well this is where it comes into use.

Issue the below commands at a command prompt from C:\OpenSSL\bin.
The first thing that you will be asked for is the pass phrase from the rootca we entered when creating the initial rootca files

openssl ca -cert rootca.crt -keyfile rootca.key -out vsphere.crt -config openssl.cfg -infiles vsphere.csr

openssl ca -cert rootca.crt -keyfile rootca.key -out vcenter.crt -config openssl.cfg -infiles vcenter.csr


Going back to C:\OpenSSL\bin we see 2 new files, vsphere.crt & vcenter.crt.
Double clicking these files will show that they have been signed by the Root CA.



Creating PFX

A PFX file is required for vcenter, a PFX file is the amalgamation of the certificate and its associated private key

The following command will create the PFX for vcenter

openssl pkcs12 –export -in vcenter.crt -inkey vcenter.key -name vcenter  -passout pass:testpassword -out vcenter.pfx


Again looking in C:\OpenSSL\bin you will see the newly created PFX file.

Replacing Certificates on vCenter

We now need to replace the default certificate that are installed on vcenter with are newly created certs.
The SSL certificates for vCenter are located at

C:\Users\All Users\VMware\VMware VirtualCenter\SSL

Opening this folder you will find 3 files

  • rui.crt
  • rui.key
  • rui.pfx

Copy these certificates to a safe location as you will need to replace these if anything has gone wrong with the newly created certificates.

Copy across the vcenter.crt, vcenter,key and vcenter.pfx files created earlier and rename these to reflect the original rui files

On the vCenter Server, restart the service VMware VirtualCenter Management Webservices

Installing Root CA on Windows

Now that we have out certificate signed by our Root CA we need to ensure that the Root CA is trusted by servers and clients that will be connecting to both vsphere & vcenter.

The easiest way to do is this is via a GPO

Create a new GPO and give it a meaning full name


Navigate to
Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies – Trusted Root Certificate Authority
and choose Import


Import the rootCA.crt certificate


You can now close Group Policy.

Uploading Certificates to vSphere

The part went really smoothly for me due to a PowerShell script by Martijn Baecke that’s available on the VMware communities website.

See the post at for full instructions on uploading the certs to vSphere.

Testing certificates from Clients

Finally we have everything in place and we are now ready to test the certificates for trust from out clients.

First thing to do is to issue a group policy update from the client. This will install the Root CA into the clients Trusted Root Certificate Authorities container


Once the update has been issues we can check that the certificate has been installed.

  1. Click Start, click Run, type mmc, and then click OK.
  2. In the File menu, click Add/Remove Snap-in.
  3. In the Add/Remove Snap-in box, click Add.
  4. In the Available Standalone Snap-ins list, click Certificates, and then click Add.
  5. Click Computer Account, and then click Next.
  6. Click the Local computer (the computer this console is running on) option, and then click Finish.
  7. Click Close, and then click OK.

Expand Certificates – Trusted Root Certificate Authorities – Certificates and you should now see the RootCA installed


Finally open Internet Explorer and point the browser to your vCenter URL. If all has gone correctly the page will display without the certifcate security warning.


My next post will cover using a Windows CA to sign the CSR

Posted in Certificates, OpenSSL, VMware, vSphere, Windows Servers | Tagged: , , , , , | 2 Comments »