gRPC in ARM 2020.2.2 creates new server requirements

SolarWinds introduced gRPC as a new internal communication protocol in ARM 2020.2.2. It is based on the HTTP/2 standard and protocol buffers. This creates a new requirement for the Windows servers.

What is the new requirement for ARM?

At least one of the following Cipher Suites must be active for the TLS handshake on the Windows Server with an installed ARM component (ARM server or collector):

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384

These cipher suites are active by default. If they were disabled, it was done on purpose.

The first two Cipher Suites (TLS_ECDHE…) are not available under Windows Server 2012 / 2012R2. A detailed list of the cipher suites supported by Windows can be found at Microsoft.

Do the same Cipher Suites have to be active on all servers?

No, there does not have to be a match of the Cipher Suites between the servers. This means it will work if e.g. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is active on the ARM server and TLS_RSA_WITH_AES_256_GCM_SHA384 is active on the ARM collector.

How do I find out which Cipher Suites are active on my server?

To check the cipher suites we recommend IIS Crypto from Nartac Software.

Simply run the program on the corresponding server and switch to Cipher Suites in the left menu and search for the corresponding Cipher Suites there. They are marked here in the screenshot:

IIS Crypto shows active Cipher Suites

All deactivated Cipher Suites can be found at the end of the list and have no tick.

How can I activate the required Cipher Suites?

You can also reactivate the required Cipher Suite via IIS Crypto by ticking the box and restarting the server if necessary.

How do the missing Cipher Suites show in ARM?

If none of the required cipher suites are available, the ARM cannot function properly because the internal TLS handshake cannot take place and the corresponding software component restarts. This is a continuous loop and ARM cannot be used.

In the log files it looks like this (abbreviated):

[    819|ARM            |armServer   |5644.1|  1|CUSATUM\SYSTEM          |SolarWinds.ARM.Remo…ertificateHttpLoader|200924|16:04:04.961|Error      ]         SslCertificateHttpLoader.LoadServerCertificate(Uri address): System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
…[    822|ARM            |armServer   |5644.1|  1|CUSATUM\SYSTEM          |SolarWinds.ARM.Remo…cClientTransportSink|200924|16:04:04.977|Error      ]         GrpcClientTransportSink.sendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream): System.Runtime.Remoting.RemotingException: An error occured when communicate to ‚grpc://arm.cusatum.de:55555/tracerServer‘! —> SolarWinds.ARM.Remoting.GrpcRemotingException: Could not load certificate from ARM-Server

–BEGIN-OF-EXCEPTION————————————————————

System.Runtime.Remoting.RemotingException: An error occured when communicate to ‚grpc://arm.cusatum.de:55555/tracerServer‘! —> SolarWinds.ARM.Remoting.GrpcRemotingException: Could not load certificate from ARM-Server

at SolarWinds.ARM.Remoting.GrpcRemotingChannelManager.GetClientChannel(String host, Int32 port)

at SolarWinds.ARM.Remoting.GrpcClientChannel.GrpcClientTransportSink.sendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream)

— End of inner exception stack trace —

–END-OF-EXCEPTION————————————————————–

If you need further information, please send us an eMail to info@cusatum.de or use our contact form.