OMI with WSMan over HTTPS: Done right.
When you install OMI for the first time, a pair of keys is generated for you. When an automated process is used, the only option that will “just work” is to generate self-signed certificate. The logical next step is to convince your machine that it should connect to OMI server even though it doesn’t really trust this certificate. Therefore most of examples that use CIM connection to OMI server you will find will look like this:
|
|
Good for very basic demos but if you consider using OMI and/or Linux DSC in the production environment you shouldn’t depend on automatically generated, self-signed certificate. The whole point of communication over HTTPS is that both devices on each side of the wire know and trust each other. With self-signed certificates it becomes false-protection, a security not applied.
If you have internal PKI, it’s relatively straight-forward to create proper, domain-wide trusted certificate for any network device. Existence of the internal PKI should be a safe assumption: any organization that uses SSL and doesn’t have own PKI is either wasting money on 3rd-party certificates or is “doing it wrong” for any SSL-based application.
First thing we have to do is to generate certificate request and private key on Linux machine. To achieve this we will use openssl command. To avoid prompts we will provide all parameters inline. To call commands on Linux we will use Posh-SSH module, described here:
|
|
Request file (omi.req) needs to be copied from Linux box to our Windows system. There are many methods to achieve this; we will use another part of Posh-SSH module, Get-SCPFile command. Just to be sure we are using correct file we will first remove any files with base name omi already present in the c:\temp folder:
|
|
Next step requires communication with an internal CA. We will use traditional certreq.exe tool to perform this operation:
|
|
The procedure to request/issue certificate may differ in your environment: in my case I had certificate template “SSL” available for me that suits the requirements of OMI certificate and I had necessary rights to get the final certificate immediately.
Next step is to copy the certificate back to our OMI server. For that we will use Posh-SSH again, this time Set-SCPFile cmdlet to copy a local file to the remote system:
|
|
We have our certificate ready, but the file format does not match the one used for the private key. We need to convert it to the correct format using openssl command. With the both files ready we can copy existing files (just in case) to separate folder, replace certificate with the one we trust and restart OMI server:
|
|
The command used to restart OMI service depends on the tool that is used to control the services on the Linux box. In my case (CentOS 7) it was systemd/systemctl.
Our OMI server is using a proper certificate, so we should be able to connect to it without any of the switches that we’ve used before to accept self-signed certificate. Once connected, we ask for instance of OMI_Identify, to make sure we are talking to the correct server:
|
|