07-22-2019 07:21 AM
Hi,
I hope somebody out there has an idea...
We are just configuring the Geospatial Portal (APOLLO 2018 U4) at customer site. In order to access the Internet we need to hit a proxy server.
Thus we changed the web.config of the portal. Here we added the following lines in the system.net part of the xml:
<defaultProxy> <bypasslist> <add address="[a-z]+\.smul\.sachsen\.de$" /> </bypasslist> <proxy proxyaddress="http://xxx.smul.sachsen.de:80" bypassonlocal="true" /> </defaultProxy>
After this change we are able to access servers (e.g. WMS services) on the internet. But only those servers which are accessible via http. If we try to hit a server via SSL we do get the error message "Could not create SSL/TLS secure channel" in the add wms dialog.
I assume that this is caused by the TSL version missmatch - 1.2 versus 1.1. But I have no idea where to start to solve this issue. Is it on the portal side, on the .Net version, Windows server (2012 R2) settings or settings on the proxy server.
Any idea is more than welcome.
Cheers and many thanks for your help in advance.
Fritz
Solved! Go to Solution.
07-22-2019 08:37 PM
Not sure if this is your problem, but if an service (WMS, WFS etc) is provided by a server that only has TLS 1.2 enabled, then Geospatial Portal 2016 (and I think 2018) will fail to connect to it.
e.g.
In my scenario the error I received was 'The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.' (From the Geospatial Portal log file).
If that turns out to be your situation, I was able to work around it by adding some registry keys forcing TLS support by .net
(It’s the older version of .net used by Geospatial Portal that does not handle TLS by default from my understanding/googling).
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SchUseStrongCryptoregistry key has a value of type DWORD. A value of 1 causes your app to use strong cryptography.
The HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SystemDefaultTlsVersions registry key has a value of type DWORD. A value of 1 causes your app to allow the operating system to choose the protocol
In both cases <VERSION> is v4.0.30319
See
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls#schusestrongcrypto
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls#systemdefaulttlsversions
for details on setting up the two keys.
After the change I could view the WFS feed provided from an TLS 1.2 only environment in Geospatial Portal.
07-23-2019 04:27 AM
Thanks a lot for your help Shaun,
it is working now. First I added both REG-entries. After this change I was able to load all external WMS coming via https. But SSO within the portal (Login into the APOLLO catalog via the kerberos ticket) did not work anymore.
So I removed the "SystemDefaultTlsVersions" Dword and now both things are working: SSO and the access to WMS services using https.
Cheers
Fritz