Solarwinds hat bei ARM 2020.2.2 gRPC als neues internes Kommunikationsprotokoll eingeführt. Es basiert auf dem Standard HTTP/2 und Protocol Buffers. Hierbei ist aber eine neue Voraussetzung bei den Windows Server geschaffen worden.

Was ist die neue Voraussetzung für ARM?

Es muss mindestens einer der folgenden Cipher Suites für den TLS Handshake auf dem Windows Server mit der ARM Komponente (sowohl ARM Server als auch Kollektor) aktiv sein:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384

Regulär sind diese Cipher Suites aktiv. Wenn sie deaktiviert wurden, so geschah dieses absichtlich.

Die ersten beiden Cipher Suites  (TLS_ECDHE…) sind nicht unter Windows Server 2012/2012R2 verfügbar. Eine ausführliche Liste der von Windows unterstützten Cipher Suites kann man bei Microsoft finden.

Müssen auf allen Servern die gleichen Cipher Suite aktiv sein?

Nein, es muss kein Match der Cipher Suites zwischen den Servern geben. Es funktioniert also, wenn z.B. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 auf dem ARM Server und TLS_RSA_WITH_AES_256_GCM_SHA384 auf dem ARM Kollektor aktiv ist.

Wie stelle ich fest, welche Cipher Suites bei meinem Server aktiv sind?

Um die Cipher Suites zu überprüfen empfehlen wir IIS Crypto von Nartac Software.

Einfach das Programm auf dem entsprechenden Server ausführen und im linken Menü zu Cipher Suites wechseln und dort nach den entsprechenden Cipher Suites suchen. Sie sind hier im Screenshot markiert:

Alle deaktivierten Cipher Suites sind am Ende der Liste zu finden und haben keinen Haken.

Wie kann ich die benötigten Cipher Suites aktivieren?

Über IIS Crypto können Sie die benötigte Cipher Suite auch wieder aktivieren, indem Sie den Haken setzen und gegebenenfalls den Server neu starten.

Wie wirkt sich die fehlende Cipher Suite aus?

Wenn keine der benötigten Cipher Suites zur Verfügung steht, kann ARM nicht richtig funktionieren, da der interne TLS-Handshake nicht stattfinden kann und die entsprechende Softwarekomponente startet neu. Das ist dann eine dauerschleife und ARM kann nicht genutzt werden.

In den Logfiles sieht das wie folgt aus (gekürzt):

[    819|ARM            |armServer   |5644.1|  1|CUSATUMSYSTEM          |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|CUSATUMSYSTEM          |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————————————————————–