ssl

MeshCentral – Certificate installation

MeshCentral - Certificate installation

MeshCentral is a remote support OpenSource platform. It runs on Windows or Linux and needs to be self hosted.

While it supports Let’s Encrypt (letsencrypt.org) certificates, this is not always a possible option. Issues you can run in to are:

  • port 80 incoming is blocked by your internet provider
  • your DNS provider does not support the ACME protocol needed

Of course, you also could just simply want to create your own certificate. To do so you go to your regular CA (certificate authority) provider and get your certificate issued. You can do so by simply engaging Windows IIS, request a new certificate per CSR, have it issued and finalize the request in IIS. Your last step is to export it including the private key.

Transfer this file now to your MeshCentral server (just use MeshCentral to transfer the file). Next you will need OpenSSL – what is often pre-installed on Linux and Raspberry, on Windows you will need to download it separately.

OpenSSL is used on the command line to extract the unencrypted key and the separate the certificate so MeshCentral can use it. Follow the next steps – while we assume your source certificate file is named source.pfx.

  1. openssl pkcs12 -in source.pfx -nocerts -out encryptedkey.key
    1. this will ask for the password for source.pfx
    2. it will also ask and have you confirm a new password (can be the same) for the destination file
  2. openssl rsa -in encryptedkey.key -out webserver-cert-private.key
    1. it will ask your for the new password of the file you created in step 1
    2. this will overwrite the webserver-cert-private.key file with a passwordless key-file as needed by MeshCentral
  3. openssl pkcs12 -in source.pfx -clcerts -nokeys -out webserver-cert-public.crt
    1. this will ask for the password for source.pfx
    2. it will overwrite the webserver-cert-public.crt file with the public part of your certificate

Now reboot the MeshCentral service/server and open a new browser window, you certificate should work now.

 

Secured WinRM SSL session and PowerShell WinRM queries – example with a PRTG sensor for CPU, HDD and RAM

Secured WinRM SSL session and PowerShell WinRM queries – example with a PRTG sensor for CPU, HDD and RAM

Windows Mangement Remote Mangement / WinRM can be configured as HTTPS / encrypted connection instead of using clear text transfer of the provided information. In order to do this you need to configure it accordingly and have a valid machine certificate installed on the system.

Now – the advantage here is clearly the added security layer while you request and receive those information. More information on how to do this can be found here: https://support.microsoft.com/en-us/help/2019527/how-to-configure-winrm-for-https

Only it becomes a challenge when you want to use PowerShell and e.g. PRTG to use this HTTPS encrypted system. I came across this request and had to create a script that actually works with such an HTTPS encrypted SSL session to WinRM. You can find it below.

What it does is rather simple:

  • set the CimSessionOptions to use SSL
    • additionally it bypasses the certification checks by default – you might want to adjust this depending on your network configuration
  • it creates a new CimSession to your target system using the UseSSL option
  • and finally it executes a few queries against this session
  • the data in this example is then translated in to a PRTG compatible XML structure so you could use it in a Advanced EXE/XML sensor within PRTG

The data in this example combines information about the CPU(s), HardDrives / HDD(s) (only installed drives, not USB) and Memory usage to PRTG in a single sensor while using channels.

Due to some dynamic of the script, you want to make sure you have fixed upper and lower error limits on especially the channel Total Disks – so if something changes you can re-create the sensor due to it’s fixed channels once it did run the first time.

In theory you could provide limits within the XML response to PRTG – this is up to you – I always liked it more to configure them solely in PRTG in the sensor channels so I could adjust them per device.

PS: This was originally posted in the private PRTG channel on SpiceWorks here.