Configuring a remote CSP Gateway for serving with SSL/TLS/HTTPS

Hello everyone smiley

I have a server configuration in a CSP Gateway installed on a PC (let's call it S2) different from the main one (let's call it S1). This configuration allows me to access a web application that is installed on S1, from a client C asking S2 for this webapp. But for now it works only in HTTP between C and S2, and we would like to use HTTPS (as it already works between S2 and S1).

First here are the tutos found in the doc:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

I have tried in many ways using certificates that I have got from a colleague, but I always get an ERR_SSL_PROTOCOL_ERROR or an "unavailable web page/server" error. Could you please take a look on what I've done and tell me if you see anything weird or wrong ? Tutorials in the doc lead me to try:

-Configuring the S2's CSP gateway server access (I notice that I can access to the webapp in HTTP from S2 only if the connection security level is set to "none" (not SSL) in this screen)

-Changing CGI environment variables in related webapp config

-Creating SSL/TLS configurations in S1's Healthshare portal (also tried with a %SuperServer... but where and how could I use them ? I haven't found it)

-Looking into S2's IIS installed certificates... but it seems not linked to S2's CSP Gateway as the HTTP webapp does not go down when I stop the default web site in IIS;

-configuring file SSLdefs.ini following this tutorial: https://community.intersystems.com/post/configuring-cach%C3%A9-client-ap... (...but once more it does not seem to have any effect on the webapp)

So what should I try next ? smiley

Have a nice day !

Mathieu

Answers

There are two different connections here - one from the browser to the webserver, and one from the CSP gateway to Cache. Either or both can use SSL and they are configured separately.

You said you want HTTPS. This would be used on the connection between the browser and the webserver. It does not involve Cache or the CSP gateway at all. It is configured entirely in the web server configuration. For example, if you are using Apache, it is configured in the httpd.conf and related Apache conf files.

The settings you've shown above are for the CSP gateway to Cache connection. If the gateway and Cache are on separate machines, you may also want to configure SSL for this connection. The gateway will be connecting to the SuperServer on Cache, so you will want to follow the instructions for configuring SuperServer SSL if you want to get this part working. The instructions for that are here:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

Hello Katherine, thank you for your answer.

I have configured Apache in my server S2, and it seems to work as expected now, after having added those lines to httpd.conf :

LoadModule ssl_module modules/mod_ssl.so
Listen 443
<VirtualHost *:443>
    ServerName myhost.mydomain.be
    SSLEngine on
    SSLCertificateFile "D:/pathToMy/certificate.cer"
    SSLCertificateKeyFile "D:/pathToMy/certificate.key"
    SSLVerifyClient optional
    SSLVerifyDepth 1
    SSLCACertificateFile "D:/pathToMy/certificateCA.crt"
</VirtualHost>

Best regards :-)

-Creating SSL/TLS configurations in S1's Healthshare portal (also tried with a %SuperServer... but where and how could I use them ? I haven't found it)

Your SSL configuration should be called %SuperServer. Currently it's called AccDirSsl. You need to create new/rename existing configuration to %SuperServer.

 

Also, can you show a screen from the Portal’s System-wide Security Parameters page (System Administration > Security > System Security > System-wide Security Parameters)? For the Superserver SSL/TLS Support choice, you should select Enabled (not Required).

 

Also does HS OS user has access to C:\chr11614pem? I'd try to copy certificates/keys to HS temp directory and modify paths in config accordingly.

Hello everyone smiley

Well it seems that being able to reach the webapp via HTTPS does not secure the TCP messages between the remote CSP Gateway and the main Ensemble server (port 1972).

Until now in the gateway I did not use the "SSL" connection security level in the server configuration page, so I guess I have to do it now.

So I have filled in the related fields, in the way described in the 1st picture from the 1st post of this topic. And following the link and advices from Katherine and Eduard that were previously given in the answers here, I have also created the %SuperServer configuration in the main server, as described in the picture below:

 

But then I get an error 500 ("Server is currently unavailable").

Do you know where it could come from ?

Best regards.

Have you also enabled SuperServer SSL/TLS? You can do this in the portal at the System Administration > Security > System Security > System-Wide Security settings page.   

If that doesn't help, I would recommend running the REDEBUG routine on the server to enable network debugging, then trying the connection from the gateway again. You can turn the network debugging on like this:

%SYS>d ^REDEBUG

Old flag values = FF

New flag values (in Hex): FFFFFFFF

Done

%SYS>

The logging information will be in the cconsole.log file.  Remember to set the flags back to FF when you're done to disable collection.

The CSP gateway event log may also be useful.  You can access this through the gateway management page.  It may be helpful to clear the log, then try the connection again, so that you see only the messages related to your test.

Finally, I see that you've edited the enabled protocols.  I would recommend you use the defaults unless you have a specific reason why you need to enable a protocol with known problems, such as SSLv3.   

Hello Katherine, thank you for your answer.

First just FYI, SuperServer SSL/TLS was already enabled and I have changed (back) the enabled protocols to match the default ones.

Then I have done the suggested tests; here is what I found in cconsole.log:

tpopen for host  device number 1972 port 1972  mode 0x208 tcpmode 0x0 terminators  ibfsz 1024 obfsz 1024 queuesize 5 timeout 2 tcpsbuf=0 tcprbuf=0, XY=on, BINDTO=
NETSEC_AcceptServerContext
netsecAcqSrvCred
netsecAcqSrvCred --> returns 1
netsecAcceptServerContext(ddbp=0xbbe1d4f0)
AcceptServerContext: peek saw no preamble
SSL/TLS configuration: %SuperServer
Cipher list: ALL:!aNULL:!eNULL:!EXP:!SSLv2
Certificate file: C:\chr11614pem\chr11614.pem
Setting private key file encryption password
Private key file: C:\chr11614pem\chr11614.key
Trusted certificate file: C:\chr11614pem\DigiCertCA.pem

Peer verification option = 1, certificate depth = 9
SSL/TLS server requested.
Verify error with X.509 certificate at depth 0
Subject: /C=BE/L=Liege/O=CHR de la Citadelle/OU=IT/CN=*.chrliege.be
Issuer: /C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
Error: 20, unable to get local issuer certificate
SSL/TLS error return from SSL_accept().
SSL_ERROR_SSL: protocol error
error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed

...So we can see some explanations, although I don't know yet how to fix this. What seems weird to me is the "empty" host name in the first line (in other connection attempts I can see for example "tpopen for host CHR11832 device number 2120 port 2120" etc.).

Don't hesitate to tell me if you know what could help me smiley

Best regards

The "Error: 20, unable to get local issuer certificate" means you don't have one or more certificates in your server's trusted CA file needed to verify the client's certificate.  It looks like the certificate for  "/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3" probably isn't in the DigiCertCA.pem file.  It's possible that you don't want to trust that CA (and therefore this is being correctly rejected) or that you do want to trust it and that certificate should be added to the file. 

Are the other connection attempts you see with empty hostnames for ones where Cache is the server, or the client?  I wouldn't be surprised if the hostname isn't displayed when Cache is the server since in that case you don't pass a hostname to the open command.

It seems that the missing certificate was indeed the source of the problem. I have been helped by a colleague for adding it in the DigiCertCA.pem file, and that solved the problem. Thank you again for your advices smiley