Using certificates SCOM

CA Server – We have a single stand-alone CA server, which only purpose is to create certificates for the SCOM 2007 environment. The root CA is called JAMA00.
Requesting a certificate – From the target server (running the agent), we have no access to the CA server’s web interface. Therefore we must manually generate a certificate request and upload this request to a central file share.


Creating a certificate – We have automated the process of picking up the certificate requests (from the central file share) and generating a certificate file. We also generate an executable installer file, which will install the newly generated certificate on the target server and will configure SCOM to use this certificate for communication with our environment.
Importing a certificate – We support several ways for importing the certificate at the target server. This can be done before, during or after the SCOM agent has been manually installed (as long as our scripted version of the manual installation is used).

---

CA Server – Default a certificate issued by a CA is valid for one year. To prevent us from replacing all certificates after a year we have changed the configuration, so certificates are valid for a period of 100 years. See this Microsoft article on how to make these settings:

But since a certificate can not surpass the lifetime of the root CA, we have also set the expiration date of the root CA certificate to 100 years:

So effectively, all certificates are valid until the expiration date of the root CA certificate.

---

Requesting a certificate – To request a certificate, the certreq.exe application must be available on the system. This is default the case for all versions of Windows, with the exception of Windows 2000.
Remember that we do not have access to the web interface of the CA server, so we make a manual request from the command line.
The certreq.exe must be supplied with a file which describes the required certificate for which a request file must be generated. This file should contain this information:

[Version]
Signature= "$Windows NT$"
[NewRequest]
Subject = "CN="
KeySpec = 1
KeyLength = 1024
KeyUsage = 0xa0
ProviderName = "Microsoft RSA Schannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
Exportable = TRUE
MachineKeySet = TRUE
UseExistingKeySet = FALSE
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1
OID = 1.3.6.1.5.5.7.3.2

must be the FQDN of the server when it is a domain member or the computer name when it is a workgroup server.
It is possible to set the value for “Exportable” to “FALSE”, so the private key is no longer exportable. However Microsoft states that the private key must be exportable (I don’t know why).
When we name this file: certreq.inf, the command to generate a certificate request file will become:

certreq -new -q -f certreq.inf certificate.req

This will generate a request file called: “certificate.req”
We have scripted all of these steps and made sure that the actual name of the request file is set to the FQDN of the computer generating the request. This will prevent any duplicate name issues when copying the request file to the shared location. So in general terms we execute:

certreq –new –q –f certreq.inf .req

And here the part is the FQDN of the computer (or the computer name for workgroup computers). So we now have a certificate request file, which name is unique in the SCOM environment.
This certificate request file can now be placed on the central file share.

---

Creating a certificate – After the certificate request file has been placed on the central file share, the request file will be processed by a script to generate the required certificate file for the target server.
To generate a valid certificate, the following steps are performed:

 Submit the request

To submit the request, the following command is given on the CA server:

certreq -submit -q -config ""

Where equals the FQDN of the CA server and is the request file from the target server.
This command will pass back an Id, which we can use in the next step of processing the certificate request. The certificate is now in the pending state and must be issued before it can be used.

Issue the request

To issue the request, the following command is given on the CA server:

certutil -resubmit

Here is the Id that was passed back from the submit command in the previous step. When completed, the certificate is issued and ready for use. We can now retrieve the certificate and use it at the target server.

Retrieve the certificate

To retrieve the request, the following command is given on the CA server:

certreq -retrieve -q -config "”

Again the equals the FQDN of the CA server, the equals the Id that was passed back from the first step and is the name for the retrieved certificate.
So when all is finished, we have a certificate file called , which can be imported on the target server that generated the certificate request file.
To make life easier we gave the final the same name as the FQDN of the target server, followed with the .cer extension.
So if a server is called “server01.company.local”, the final certificate file that is generated is called “server01.company.local.cer”.

Importing the certificate

To import the certificate, the newly generated certificate must be “accepted” by the machine that generated the certificate request. The following command is given on the target server:

certreq.exe -accept –q “"

This command will make the certificate file available for use on the target machine. Again, is the certificate file generated in the previous step.

Configuring SCOM agent

The final step in this process is to configure the SCOM agent to use this certificate for communication with the SCOM management servers. To do this, this command is given on the target server:

MOMCertImport.exe /SubjectName

Here is the FQDN of the target server and this should be equal to the FQDN used in the certificate.
After a restart of the SCOM agent, the agent will start communicating with the management servers, using the certificate.

Certificate installer package

When the certificate request is generated on the CA server, we also package this certificate file into an installer executable, which contains the certificate and a script that will accept this certificate on the local server and instruct the SCOM agent to start communicating, using this certificate (combining the import and configuring steps mentioned above).

---

The root CA certificate – Now this all works great, as long as both the agent and the management servers use a certificate generated by the same CA and do trust this CA.
The management servers are given a correct certificate and the root CA certificate during installation of the management server.
The target servers (running the agents) must also have the correct root CA certificate in the “Trusted Root Certification Authorities” in the local computer store.

We have completely scripted the (manual) installation of the agent and part of this script is the import of the root CA certificate in the “Trusted Root Certification Authorities” of the local computer.
This is done by running this command on the target server

certutil.exe –addstore root

The must be replaced with the root CA certificate file (JAMA00.cer in our case), which holds the root CA certificate.