A lot people might think, why should I monitor expiring certificates with System Center Orchestrator 2012. There are already solutions to monitor certificates in the local store on Windows computers – for example the wonderful solution from Raphael Burri (PKI Certificate Verification MP).
But we had an issue with an expired certificate on non-windows systems. With that problem the idea came up to directly query expired certificates from the certificate authority (CA) – our internal cert store. We also wanted to notify the requesters directly, when a certificate expires within the next 30 days, send him/her reminders and last but not least inform the management a few days before the certificate expires, if no one has taken an action. With that idea we through about an automation solution – System Center Orchestrator.
Here is the description of the solution.
Prerequisites:
- System Center Orchestrator 2012 R2
- Exchange Mailbox to send and receive emails and a user which has permissions to it
- Exchange Users Integration Pack
- PS PKI PowerShell module installed on all Runbook servers
- Microsoft Certification Authority
- SQL Temp database (Orchestrator Temp)
Temp Database config:
Mailbox folders:
Exchange Users Integration Pack Config:
GetEmail:
Move Email:
For both configurations you need to know the path of your Exchange Server EWS service: https://autodiscover.fqdn/EWS/Exchange.asmx and the user with domain and password, which owns the mailbox.
After importing the runbooks, you will also need to configure the SQL activites (enter DB instance and Database) and the Send email activities (SMTP server and addresses). There will be some more things to change, but I will mention them in the runbook descriptions.
I suggest to run the runbooks through a scheduled task on a daily basis.
The first runbook reads the certificates and writes them to the database:
Certificates.WriteToDB
Update the template list, you want to check, in the GetCerts Activity:
$Templist=@(
“WebServer”, #Web Server
“1.3.6.1.4.1.311.21.8.15817755.12287325.10963384.6580300.14252506.110.2574398.13148790” #Web Servers
)
Enter the names of the CAs which should be checked:
$canames=@(‘CA1FQDN‘,’CA2FQDN‘)
Certificates.GetRequesterEmail
Update the domain names and FQDNs which should be checked in the Get Requester Email activity.
function get-domain($dn)
{
if($dn -like “*,dc=domainshortname1*”){$domain = “domain1fqdn“}
if($dn -like “*,dc=domainshortname2*”){$domain = “domain2fqdn“}
return $domain
}
Now that we have all expiring certificates in the database, we need a runbook, which sends out the notifications.
Certificates.Notifications
The first email will be send out when 30 days are left and it should be send to the service desk to create a ticket. The requester will be on CC. The second email is send to the requester from day 29 to day 4. And then the last emails will be send to the management and the requester as CC.
We also created two additional runbooks to update the requester, if this information is not current anymore or to stop the notifications, if the certificate is already extended.
The requester has the option in his emails to click on a link which creates a new pre-filled email for both situations. If the certificate PPR changed, then he/she should enter the email address of the new PPR into the CC field and send the email. If the certificate was extended, then he/she only needs to send the email.
The emails will be sent to the mailbox for which we configured the Exchange User IP before.
Information:Certificate extended email
Information:Change certificate PPR email
Certificates.UpdateRequesterEmail
This runbook takes the email address of the CC field and writes it to the database, then it moves the email to the Certificates.NewRequester folder in the mailbox.
Certificates.SetDeleted
This runbook only sets a field in the database to deleted for the mentioned certificate in the email. Then it moves the email to the Certificates.Finished folder in the mailbox.
This is the whole solution.
You can download it from github.
Most of the activities are PowerShell activities, so it should not be a big effort to also migrate the runbooks to Azure Automation or SMA.
SystemCenterTipps 