Review and test TLS Client Certificate Authentication

[lazyfrosch]

WinRM and the plugin support authentication via a certificate instead of credentials.

• [ ] Check how much usable this is in a Windows world
• [ ] Does the implementation work correctly?
• [ ] Document usage

[K0nne]

Hi!

I tested the latest release against our own test server:

./check_by_powershell-linux-amd64 --version
check_by_powershell version 0.2.0 - 72488a89b2e9fcf36e244b3394687e23838af55f

Test1:

./check_by_powershell-linux-amd64 --host 'IP' --auth NTLM --user 'DOMAIN\\USR' --password 'PWD'  --icingacmd 'Invoke-IcingaCheckCPU'
./check_by_powershell-linux-amd64 --host 'FQDN' --auth NTLM --user 'DOMAIN\\USR' --password 'PWD'  --icingacmd 'Invoke-IcingaCheckCPU'

Here we get the following error:

UNKNOWN - execution failed: execution of remote cmd failed: http response error: 401 - invalid content type

Test2:

./check_by_powershell-linux-amd64 --host 'IP' --auth NTLM --user 'DOMAIN\USR' --password 'PWD'  --icingacmd 'Invoke-IcingaCheckCPU'
./check_by_powershell-linux-amd64 --host 'IP' --auth NTLM --user 'USR' --password 'PWD'  --icingacmd 'Invoke-IcingaCheckCPU'
./check_by_powershell-linux-amd64 --host 'FQDN' --auth NTLM --user 'DOMAIN\USR' --password 'PWD'  --icingacmd 'Invoke-IcingaCheckCPU'
./check_by_powershell-linux-amd64 --host 'FQDN' --auth NTLM --user 'USR' --password 'PWD'  --icingacmd 'Invoke-IcingaCheckCPU'

With the other spelling of the user we get this message: UNKNOWN - execution failed: execution of remote cmd failed: Command has already been closed

We will investigate this with our colleagues.

[lazyfrosch]

This issue is only related to TLS Client Certificate authentication, and not any other TLS topic

[brajjan]

We are currently testing out check_by_powershell in an attempt to migrate from NSClient++ and we have done some tests with certificate based auth - might be useful information for you so I'll post our results here..

All tests were made with the following version check_by_powershell version 0.3.0

Certificate based auth is possible as long as you are connecting to a server that does not have TLS 1.3 activated. Windows Server 2022 is the only OS (right now) that have TLS 1.3 support and is enabled by default. When using TLS 1.3 the following error occurs

[user@server ~]# /home/user/check_by_powershell -H server2022.fqdn -p 5986 --cmd whoami --auth TLS --ca /home/user/ca.pem --cert /home/user/cert.pem --key /home/user/key.pem
WARN[0000] auth type is TLS, but TLS certificates are supplied
UNKNOWN - execution failed: execution of remote cmd failed: unknown error Post "https://server2022.fqdn:5986/wsman": read tcp [client-ip]:26210->[server-ip]:5986: read: connection reset by peer

The problem seems to reside within Windows and only when connecting using certificate. When using basic auth to connect to a TLS 1.3-activated server it all works fine.

[user@server~]# /home/user/check_by_powershell -H server2022.fqdn -p 5986 -U icingauser -P icingapass --cmd whoami --auth=basic --ca /home/user/ca.pem
server2022.fqdn\icingauser

And when using certificate based auth when TLS 1.3 has been disabled on the server

[user@server ~]# /home/user/check_by_powershell -H server2022.fqdn -p 5986 --cmd whoami --auth TLS --ca /home/user/ca.pem --cert /home/user/cert.pem --key /home/user/key.pem
WARN[0000] auth type is TLS, but TLS certificates are supplied
server2022.fqdn\icingauser

When investigating network traffic using wireshark it tries to use TLS 1.3 but server downgrades to TLS 1.2 and communication continues. No errors there, but for some reason the server terminates the session when using TLS 1.3 and certificate based auth.

To make check_by_powershell work with certificate based authentication on Windows Server 2022, you need to disable TLS 1.3. This can be done by modifying the registry

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -name 'Enabled' -value '0' –PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -name 'DisabledByDefault' -value '1' –PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'Enabled' -value '0' –PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'DisabledByDefault' -value '1' –PropertyType 'DWORD'

A workaround could also be to make create a new parameter to force TLS 1.2. We did the tests with the winrm library rebuilt with MinVersion and MaxVersion set to TLS 1.2. But I think that the main issue is with Microsoft.. But it would be awesome if a newer release added the tls parameter

Another thing to mention is the warning that sould not occur when using auth TLS. WARN[0000] auth type is TLS, but TLS certificates are supplied