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:
Signature= "$Windows NT$"
Subject = "CN=
KeySpec = 1
KeyLength = 1024
KeyUsage = 0xa0
ProviderName = "Microsoft RSA Schannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
Exportable = TRUE
MachineKeySet = TRUE
UseExistingKeySet = FALSE
OID = 220.127.116.11.18.104.22.168.1
OID = 22.214.171.124.126.96.36.199.2
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.reqThis 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.infAnd here the
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 requestTo submit the request, the following command is given on the CA server:
certreq -submit -q -config "Where
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 requestTo issue the request, the following command is given on the CA server:
Retrieve the certificateTo retrieve the request, the following command is given on the CA server:
certreq -retrieve -q -config "Again the
So when all is finished, we have a certificate file called
To make life easier we gave the final
So if a server is called “server01.company.local”, the final certificate file that is generated is called “server01.company.local.cer”.
Importing the certificateTo 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,
Configuring SCOM agentThe 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:
After a restart of the SCOM agent, the agent will start communicating with the management servers, using the certificate.
Certificate installer packageWhen 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 rootThe