In almost every SCOM environment I have been involved with the need to monitor certificates has come up.  This is the standard management pack I use.

Requirements:

1. Powershell - The management pack works on Windows 2003, but it does need powershell to be present on all agent computers.
2. Agent Proxying - To prevent an alert storm if the same certificate is about to expire on many machines, we monitor identical certificates as a non-hosted entity.  To discover this, agents must be allowed to proxy.  Agent Proxying is not enabled by default.  Please note that if you enable proxying after deploying this management pack, you will need to restart the agent health service to get the agent to resubmit the discovery.
3. SCOM 2007 R2 or SCOM 2012.

You can also enable agent proxying via powershell.

SCOM 2012 Syntax:

Get-SCOMAgent | where {$_.ProxyingEnabled.Value -eq $False} | Enable-SCOMAgentProxy

SCOM 2007 Syntax:

$agentlist = get-agent | where {$_.ProxyingEnabled.Value -eq $False}
Foreach ($agent in $agentlist)
{
  $agent.ProxyingEnabled = $true
  $agent.ApplyChanges()
}

This is a library management pack.  So be default it doesn't do anything.  I'm including an example management pack that uses it.  I have found that certificates are used so differently by organizations that it is hard to make a discovery rule that would result in just the right level of monitoring for the organization.

I provided one discovery data source

• Microsoft.Windows.Certificates.Discovery.DS - You can target it at a windows computer, or any class hosted by a windows computer.  There are options to discover or ignore all certificates in the computer's Personal, Root, and Intermediate certificate stores.

I can't possible anticipate the needs of every organization, so if you need a more granular discovery, I'm providing an unsealed version of the management pack, so you can edit the "WHERE" part of the powershell script to suit your own needs.  Just change this line in Microsoft.Windows.Certificates.Discovery.DS

$colcert = Get-ChildItem -recurse cert:localmachine\ | WHERE {$_.Thumbprint -ne $null}

To something like this, or whatever meets the needs of your organization.

$colcert = Get-ChildItem -recurse cert:localmachine\ | WHERE {($_.Thumbprint -ne $null) -and ($_.Subject -notmatch "abcd") -and ($_.Issuer -match "qwerty")}

I provided two monitor types

• Microsoft.Windows.Certificates.Expiration.Monitor - Checks to see if a certificate is nearing expiration.  If the certificate does not exist, this is not considered to be an error.
• Microsoft.Windows.Certificates.Exists.Monitor - Checks to see if a certificate exists.  The certificate's expiration date is ignored.

The monitors do not have to be targeted at certificates.  You can target them at any hosted class so long as you can provide a valid principal name, thumbprint, and store.

Values to use for Store

• My = Personal
• Root = Trusted Root CA's
• CA = Intermediate CA's

Thumbprints should be provided without spaces.  For example: 97817950d81c9670cc34d809cf794431367ef474

There are also a couple of state views that show the discovered certificates as both hosted and non-hosted.

 The example management pack does the following:

1. Discover all certificates in the personal certificate store of all windows computers
2. Overrides their expiration warning threshold to 14 days
3. Checks to see if the "GTE CyberTrust Global Root" certificate exists in the trusted root certificate store

I deliberated for quite a while about whether or not to put in an active monitor by default.  Since nothing will be discovered by just the library MP, I decided to place an expiration monitor with a default warning threshold of 10 days on all hosted certificates, and an alerting monitor on the non-hosted class that contains them.  You can override the threshold and/or disable the monitor if you want to.