5. Februar 2018 09:25
Guten Morgen zusammen,
in Dynamics NAV 2017 (auch 2015, sicherlich auch 2016) bis einschließlich CU12, wird beim Aufruf einer URL per DotNet (http)WebRequest, WebClient usw. nicht auf zurückgezogene Serverzertifikate geprüft.
Während im Browser der Aufruf einer https-Seite mit zurückgezogenem Zertifikat (beispielsweise
https://revoked.grc.com) noch mit einer Fehlermeldung quittiert wird, erledigt Dynamics NAV dies ohne zu murren. Ich habe dies spezifisch für die Version 2017 von CU08 bis hoch zum CU13 geprüft, erst ab letzterem Patchstand wird auch eine entsprechende Fehlermeldung ausgegeben und die Verbindung verweigert.
Es ist mit „älteren Versionen“ damit also probemlos möglich, jedwede Adresse ohne Fehlermeldung aufzurufen.
Unabhängig von den wirklich erschreckend hohen Sicherheitsbedenken für alte Versionen, trat bei uns nach dem Update auf CU 14.1 ein Problem auf, welches erst durch aufwendige Recherchen und Tests gefunden und erklärbar wurde: In unserem Firmennetzwerk sind direkte Verbindungen ausgeschlossen. Diese müssen zwingend über einen Proxy laufen. Dieser wird auch an jeder Stelle im Programmcode korrekt gesetzt. Soweit so gut.
Nach dem Update traten beim Aufruf von https-Adressen Timeouts auf, es konnte also keine der Adressen mehr angesprochen werden. Grund dafür war der im Hintergrund stattfindende Abruf der Certificate Revocation List für das übertragene und völlig korrekte Zertifikat.
Die Adresse konnte aber nicht erreicht werden, da der Aufruf über die CryptoAPI erfolgt, die sich nicht an die an das Objekt übergebene Proxy-Adresse wendet, sondern über den Proxy, der am Benutzerprofil (IE) oder dem Computer konfguriert ist. Mehr dazu hier:
Description of the Cryptography API proxy detection mechanism when downloading a Certificate Revocation List (CRL) from a CRL distribution point.
Aus dem Text:
Note: In cases where the application itself is consuming the WinHTTP API and has set the proxy information either in the WinHttpOpen call or WinHttpSetOption call, the Crypto API does not have access to the Proxy information that the application has set and will still try to discover the proxy information as above. The usage of the WinHttp API from the Crypto API and from your own application are independent and do not share any information with each other.
Der Artikel
Certificate related problems when using a web proxy server ist in dem Zusammenhang auch recht interessant, aber vermutlich nicht 100% korrekt, da dort erwähnt wird, dass WinHTTP ausschließlich den über netsh konfigurierten Proxy nutzt. Das ist nicht korrekt, denn es gibt ein Fallback auf den im IE gesetzten Proxy für WinINet.
Setzt man also entweder den WinHTTP-Proxy oder den WinINet-Proxy, tritt gar kein Problem auf. Nur muss man halt erst einmal drauf kommen, dass mit dem CU13 etwas so einschneidendes undokumentiert passiert ist…
Falls ihr auch ein solches Problem habt, ihr wisst nun was zu tun ist. Abgesehen von einem Update auf mindestens CU13, der Sicherheit wegen...
Erschrockene Grüße,
Carsten
P.S.: Vllt. könnt ihr ja mal 2013+ testen, ob das schon immer so war. Wäre sicherlich interessant zu wissen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.