Category Archives: 14539

How to Enable Notifications for Pending Certificate Requests

You can configure a Windows Certification Authority certificate template to require CA certificate manager approval, as shown below. 

With this configuration autoenrollment is disabled and the CA Manager must approve the certificate request before the certificate is issued.

Normally, CA managers need to check in periodically to see if there are any pending requests to approve or decline.  This article discusses how to enable email notifications when a certificate request is generated that requires approval.

First, my best practice is to create a mail-enabled security group in Active Directory called CA Managers.  Add the appropriate user objects to this group and assign that group Issue and Manage Certificates and Manage CA rights on the Certification Authority, as shown below:

Now we need to configure event logging for Certificate Services for verbose logging.  Run the following command from a CMD prompt on the CA:

certutil -setreg ca\loglevel 4

You must restart the Active Directory Certificate Services service (CertSvc) to affect the logging level change.  The CA will now log event ID 54 from source CertificationAuthority in the Application event log whenever a certificate request is generated.  For example,

Log Name:      Application
Source:        Microsoft-Windows-CertificationAuthority
Date:          7/12/2012 8:16:29 AM
Event ID:      54
Task Category: None
Level:         Information
Keywords:      Classic
User:          SYSTEM
Active Directory Certificate Services left request 51 pending in the queue for C=US, S=CA, L=Pacifica, O=Expta, OU=IT, CN=Admin,  Additional information: Taken Under Submission

All we need to do now is create an Event trigger on this event.  The easiest way to do that is to create a certificate request so we can attach a task to the event it logs.  Once you create the certificate request, find the event ID 54 in the Application event log on the CA.  Right-click the event and select Attach Task To This Event.

This will open the Create Basic Task Wizard which we will use to configure the email notification.  Give the task a name and description, as shown below, and click Next:
The specific event details are prepopulated from the event we selected.  Click Next:
Select Send an e-mail from the Actions list and click Next:

Complete the details for the email, as shown below.  Enter the valid SMTP address for the CA Managers group (created above) in the To: field.  I include the URL to the CA approval page in the message text for easy access by the CA Managers.  Ensure that your CA server is allowed to send SMTP email to the SMTP server you designate in the wizard.  I use Telnet to test that.

Review the summary.  Select the check box to Open the Properties dialog for this task when I click Finish and then click Finish.

By default this task will only run when the user who created it is logged on.  Change the task to run under the NT Authority\SYSTEM account by clicking the Change User or Group button and entering the local SYSTEM account.  This will also configure the task to run whether the user is logged on or not.  Now click OK to complete the task.
You can view, change or delete this task in the Event Viewer Tasks in the Task Scheduler Library.
Test the new configuration by generating another certificate request.  All members of the CA Managers group should receive an email indicating that a new certificate request is pending, along with a link to the CA’s web approval page, as shown below:


How to recreate a lost private key for a certificate

Occasionally a certificate will become corrupt or is installed without a properly generated private key.  Such is the case with a bare CER certificate file.  When this happens it will often no longer function with Exchange, IIS, or other web servers.
Here is how to recreate the private key for an installed certificate.

  • Open the Certificates management console (Start > Run > MMC > Add/Remove Snap-in > Certificates > Computer Account > Local Computer)
  • Expand Certificates (Local Computer) > Personal > Certificates
  • View the properties of the certificate you want to create a private key for.  On the Details tab, click Serial number.
  • Copy the serial number, as shown below, to the clipboard:
  • From an elevated CMD prompt, run the following command:

certutil -repairstore my “<Serial Number>”

The output will look something like this, showing that the repairstore command completed successfully:
You will now see a small gold key in the icon for the certificate, indicating that you have the private key.  You will also see the message, “You have a private key that corresponds to this certificate” on the bottom of the properties of the certificate.

How to Easily Check for a Windows Enterprise CA

I work with a lot of different clients and often need to generate private certificates for applications, such as Exchange, Lync Server, and System Center.  I’m often surprised that clients aren’t aware if they even have a certificate authority server in their domain and if so, what it’s name is.

Here’s a simple way to check for an enterprise CA in a Windows domain.  Run the following command from a CMD prompt:
Notice the extra dash “” between the -config and -ping switches.

If there is an enterprise CA published in Active Directory, you will see a pop-up box asking you to choose the CA to ping, as shown below:

Notice that CA name and the computer that hosts it are displayed.  Once you select the certification authority and click OK, certutil will ping the server to make sure that it’s online and functioning, as shown below:


Certutil successfully pinged the CA

 If certutil is enable to locate and Enterprise CA in the domain, it will display an error message indicating that no active Certification Authorities were found:

Certutil was unable to locate an Enterprise CA in the domain


certutil -config – -ping

Replacing a Federation Trust Certificate When the Original Certificate is Missing

Exchange 2010 federation allows organizations to share calendar free/busy information (also known as calendar availability) and contact information with external recipients, vendors, partners, and customers.  This is accomplished by creating a trust with Microsoft’s Federation Gateway.  This cloud-based service offered by Microsoft acts as the trust broker between your on-premises Exchange 2010 organization and other federated Exchange 2010 organizations.  For more information about Exchange federation, see Understanding Federation.

To configure federation you install an Exchange certificate, enable the certificate for Federation, and create a federation trust with Microsoft Federation Gateway.  Eventually you will need to replace this certificate, either for business reasons or when the certificate expires.  The usual way of doing this is to install a new Exchange certificate and configure it as the “Next Certificate” in the Manage Federation Certificate wizard, as shown below.

When you’re ready to replace the current federation certificate you simply run the Manage Federation wizard, select the “Roll certificate to make the next certificate as the current certificate” check box, and complete the wizard.  What was the Next Certificate becomes the Current Certificate, and the Current Certificate becomes the Previous Certificate.

I ran into an interesting issue where the process above did not work.  The customer deleted the Current Certificate from the computer’s local certificate store, rather than roll the Next Certificate into the current certificate’s place.  This causes the Manage Federation wizard t break because it can’t locate the Current Certificate.  I was also unable to use the Set-FederationTrust cmdlet in EMS – it would give the same error:

[PS] C:\>Set-FederationTrust -Identity “Microsoft Federation Gateway” -PublishFederationCertificate
Federation certificate with the thumbprint “29FD8FFF241A4317ABAAF326226BC209F682C2F3” cannot be found.
    + CategoryInfo          : InvalidResult: (:) [Set-FederationTrust], FederationCertificateInvalidException
    + FullyQualifiedErrorId : 906B427C,Microsoft.Exchange.Management.SystemConfigurationTasks.SetFederationTrust

To fix this, you’ll need to do it using ADSIEdit.

  • Log into a computer with administrator rights and run ADSIEdit.msc
  • Connect to the Configuration naming context
  • Navigate to CN=Federation Trusts,CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
  • Right-click CN=Microsoft Federation Gateway in the work pane and select Properties
  • Edit the msExchFedOrgNextCertificate property (which contains the thumbprint of the Next Certificate) and copy the entire value.  Close the msExchFedOrgNextCertificate property.
  • Edit the msExchFedOrgPrivCertificate property (which contains the thumbprint of the Current Certificate, which was removed) and paste the value.  Click OK to set the value.
  • Wait for the change to replicate throughout your AD infrastructure.
  • From the Exchange Management Console, run the Manage Federation Wizard.  You will now notice that the Current Certificate and the Next Certificate are the same.
  • Check Roll certificate to make the next certificate as the current certificate and complete the wizard.

Don’t forget to test your configuration with the Test-Federation cmdlet.

How to Create Certificates with a Longer Validity Period

So, you have your own Windows Certificate of Authority (CA) server and you want to create some new certificates that are valid longer than the default certificate templates.  You duplicate the User Certificate, and set the validity period to 5 years.  You issue a new user certificate using the new template and discover that the certificate expires two years from today.  What’s up with that?

The validity period of any certificate generated by a Windows CA is the lesser of these three values:

  • The remaining lifetime of the root CA server 
  • The value specified in the certificate template
  • The value specified in the CA server registry (default is 2 years)

So even if you set the certificate template validity period to 10 years, certificates issued using this template will be valid for a maximum of two years with the CA’s default settings.

Increasing the CA Lifetime
Most root CAs are typically valid for 5 years. To increase the lifetime of the root CA, create or edit a text file in %SYSTEMROOT% called CAPolicy.inf with the following text:

Signature=”$Windows NT$”


Adjust the values above as needed, save the file, and restart the CertSrv service. Then renew the CA Certificate using the same public and private key pair.

Warning: If you generate a new public and private key pair you will need to reissue all your old certificates, so don’t do it unless that is your intent.

Setting the Maximum Validity Period in the Registry
The default certificate validity period configured in the CA’s registry is 2 years. To view the current registry value, run the following commands from a CMD prompt on the CA:

certutil -getreg ca\ValidityPeriod
certutil -getreg ca\ValidityPeriodUnits

To configure the registry value to 5 years, run the following command from a CMD prompt on the CA:

certutil -setreg ca\ValidityPeriodUnits 5

Adjust the value above, as needed. Then restart the CertSvc service to affect the changes.