AppInsight for IIS IP_Solarwinds_Zero_Configuration Question

stevenstadel  wrote: Our vulnerability vendor has identified the _Solarwinds_Zero_Configuration certificate that is installed when we setup AppInsight for IIS monitoring is using SHA-1 which they consider to be a weak hashing algorithm. 1. What would be the best way to ensure that SHA-1 is not used for new AppInsight for IIS monitoring going forward? 2. What is the best way to replace this certificate with a compliant version?

Hey Steve,

This was actually addressed in SAM 6.5 to switch over to SHA256. Fresh installations would have the fix. For existing installations, you'll have to manually upgrade the certificate.

Hi Serena,

Is there a KB for manually upgrading the certificate?

stevenstadel  wrote: Hi Serena, Is there a KB for manually upgrading the certificate?

If you follow this Create a self-signed certificate  it'll give you the process for updating the powershell to create your own certificate.

Working with support we found out that the current script at Create a self-signed certificate  still will only create an SHA1 certificate.

We did find a workaround. The issue was we didn't delete the old WinRM listener binding.

1. Delete the SHA1 IP__Solarwinds_Zero_Configuration certificate on the affected monitored node. (Use mmc.exe / add Certificates snap-in (Local Computer))

2. On the monitored node run this PowerShell command from an elevated PowerShell prompt.

          winrm delete winrm/config/listener?Address=*+Transport=https

3. Re-run the Auto-Configuration for the AppInsight for IIS Application Monitor

stevenstadel  wrote: Working with support we found out that the current script at Create a self-signed certificate  still will only create an SHA1 certificate. We did find a workaround. The issue was we didn't delete the old WinRM listener binding. 1. Delete the SHA1 IP__Solarwinds_Zero_Configuration certificate on the affected monitored node. (Use mmc.exe / add Certificates snap-in (Local Computer)) 2. On the monitored node run this PowerShell command from an elevated PowerShell prompt.           winrm delete winrm/config/listener?Address=*+Transport=https 3. Re-run the Auto-Configuration for the AppInsight for IIS Application Monitor

Thanks for the catch here Steve! I'll work with our team to update that page with better instructions to generate a non SHA1 certificate.

serena  wrote: stevenstadel   wrote: Working with support we found out that the current script at Create a self-signed certificate  still will only create an SHA1 certificate. We did find a workaround. The issue was we didn't delete the old WinRM listener binding. 1. Delete the SHA1 IP__Solarwinds_Zero_Configuration certificate on the affected monitored node. (Use mmc.exe / add Certificates snap-in (Local Computer)) 2. On the monitored node run this PowerShell command from an elevated PowerShell prompt.           winrm delete winrm/config/listener?Address=*+Transport=https 3. Re-run the Auto-Configuration for the AppInsight for IIS Application Monitor Thanks for the catch here Steve! I'll work with our team to update that page with better instructions to generate a non SHA1 certificate.

Steve, just following up with you here, we were able to update the script here: Success Center to generate a non SHA1 certificate

If you have a chance, let us know if that's working as you expect.

Works great! Thank you

There is a powershell script called ConfigureWsManScript-IIS.ps1 that is temporarily deployed and executed on the target node when you run CONFIGURE SERVER. You must grab this script while that step is running because it gets deleted afterwards. Its not documented by SolarWinds but if you get it then you can edit it and therefore change the WinRM settings including the SSL certificate to be whatever you want including from your internal CA servers. Then run this customized script on new IIS nodes to prep it for the AppInsight for IIS APM.

What if your are not applying AppInsight for IIS but trying to get WinRM with HTTPS working?

And it's still the same today... It's about time Solarwinds took security a bit more seriously. It's no good fixing what makes it to press, but leaving everything else there to be exploited