Go Back

https connection from openvms

I am trying to utilize the Synergy HTTP interface on OpenVMS to perform a Client Post via an HTTPS connection.

I have used the HTTP interface before, but never with an HTTPS connection.  The HTTPS aspect seems to bring in a lot of complexity regarding security: ciphers, certificates, trusted lists, etc.  All of which I have never really had to deal with before.

SSL does appear to be installed on the VMS system.  However, as best I can tell, it does not appear to have been configured, and it appears that no certificates have been created.

Does anyone have any experience is making an HTTPS connection from OpenVMS using Synergy ?   If so, would you be able to provide some guidance as to what might need to be addressed in order to get this to work ?

Thanks.

2 Answers
0   | Posted by Bill Ferris to Synergy DBL on 7/7/2022 3:05 PM
Steve Ives
IMPORTANT: Synergy 12 includes significant changes to the encryption technologies utilized on Windows and Linux systems. This response relates to the use of HTTPS on OpenVMS, and also applies to pre-V12 scenarios on all platforms.

You're right, it can LOOK complex, but in reality, you don't have to be concerned with most of it, assuming your operating system, your copy of OpenSSL (a free layered product in the case of OpenVMS), and your Synergy version are up to date. These are all really important when doing any kind of encryption. So that would be the first recommendation, get everything up to date, and keep it that way.

Beyond that, to be a CLIENT to an HTTPS service all you really need to do is use https:// in the URL you are connecting to, and obtain and specify the file spec of a "CA File" (certification authorities file) via the appropriate parameter.

Certificates are created by certification authorities. With HTTPS the certificates used for encryption are configured on and provided by the SERVER. The CA File is essentially a list of the certification authorities that you are willing to trust. So, if the server presents a certificate and you present a CA file, the runtime can check that the certificate that was presented was created by a certification authority that is listed in your CA file. If not, the connection will be rejected.

So the question is, "where does the CA file come from?" Well, maintaining your own list of the CA's to trust would be a significant (impossible for most) task, so generally people leave it up to OS vendors like Microsoft, who maintain a list of trusted CA's in the Windows operating system. Developers can export that information into a file, and convert that file into the format required by the HTTP API. This is done using a two-step process, on an up-to-date (REALLY important) copy of Windows:
  1. Export the "trusted root certification authorities" list to a P7B file.
  2. On OpenVMS, use the OpenSSL utility to convert the P7B file to a PEM file.
You can find more specific information under Exporting Certificates in the Synergy Documentation.

By the way, the list of trusted root certification authorities changes regularly, so you should implement a process to ensure that you re-generate and replace the CA file you use on a regular basis.

Of course, you could choose to specify an https:// URL and not specify a CA file at all, but I would STRONGLY DISCOURAGE you from doing that. In this scenario, there would be no validation of the certificate presented by the server, and your connection would be open to various types of exploits. You really don't want to go there.

7/7/2022 5:03 PM   0  
Bill Ferris
Steve --

Thanks for your detailed and clear response.  In particular it provided some much needed insight into what the server and client are doing to negotiate the connection.

I'll try importing and converting the CA list, and pass the CA_file parameter with the HTTP_CLIENT_POST.  

Thanks.

7/7/2022 8:09 PM   0  
Please log in to comment or answer this question.