Steve, when I worked with the WRC to configure this (back in 2015), I got significant pushback on attempting to use the "private" server. I'm not sure what will happen with an in-place upgrade, either.

That may have changed since then. Regardless, installing the CSP gateway on an external, standalone web server is a solution supported by ISC, so please take that into consideration as you plan your implementation of SSL.

Unfortunately, InterSystems doesn't support SSL/TLS on the private server.

You'll need to set up a standalone Apache server (assuming Linux/Unix), install mod_ssl, install the CSP gateway for Apache, create and install certificates, configure CSP.ini, enable TLS on the SuperServer port, and a few other things. Not for the faint of heart.

That's only half of the battle, though.

If you want to secure Studio and the ODBC drivers, you'll also need to request a special version of ServerManager.exe from the WRC that supports some additional configuration options. Enabling TLS for Studio can cause some oddities for users that rely on the ability to access the class documentation from within Studio (although that may have  been fixed; it was an issue in 2015.1).

I configured all of this for a customer in 2015 and wrote up detailed documentation. Since it was done under contract, though, it's not mine to distribute.

Brendan,

Are you fixing the documentation to remove the reference to scp, or fixing %Net.SSH.Session to support it? From the way your answer is worded, I'm suspecting the former ...

sftp and scp are individually configurable services in ssh, and in my experience you can't be guaranteed that one or the other is available at a given customer site. If scp currently isn't supported, it would be useful to have. Getting sysadmins to turn on services that are purposely disabled can be  ... challenging :)

According to the Caché log file, it's looking at the registry to get the version as well.

 

I've "hacked" around the issue by creating two registry import files, one that sets the version of the JRE to 1.8 and the other to 1.6. I import the 1.8 version (regedit /s jre18.reg) in Squirrel's startup batch file just before Squirrel is launched, and the 1.6 version after (regedit /s jre16.reg). It all happens fairly seamlessly, although I did have to insert a short delay in the batch file before the return to version 1.6 using the Win 7 'timeout' (timeout /t 1) command.

I'm attempting to use Squirrel on a Windows system with a locally-installed version of Caché/Ensemble 2014.1. Unfortunately, the version of the JRE on that system is 1.6, with which Squirrel is incompatible. Updating the JRE to 1.8 allows Squirrel to work, but breaks the JDBC gateway and client functionality in Caché. Both applications check the JRE version in the Windows registry on initialization, so messing around with PATH and CLASSPATH don't solve the problem.

Any thoughts?

 

PS. Upgrading to a more current version of Caché is not currently an option; this is a customer system.