Progress Client calling SSL API endpoint

Hi,

Can you please set/export "SSLSYS_DEBUG_LOGGING=7"  and then execute your client.

It generates a cert.client.log and attach the cert.client.log to this forum question, so that we can analyze and let you know the problem.

Thanks,

Muni

What OpenEdge version are we talking about here?

OpenEdge 12.

At the moment, I just want to know whether its possible given the information I have provided thanks.

Have you tried setting the OpenEdge environmental variables as needed:

PSC_SSLCLIENT_CIPHERS

For Windows

    set PSC_SSLCLIENT_CIPHERS=DHE-RSA-AES256-SHA

   set PSC_SSLSERVER_CIPHERS=DHE-RSA-AES256-SHA

For UNIX:

    export PSC_SSLCLIENT_CIPHERS=DHE-RSA-AES256-SHA

    export PSC_SSLSERVER_CIPHERS=DHE-RSA-AES256-SHA

Be mindful that you need to use the OpenSSL name form when setting these environmental variables.

for example :

For TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 use the name ECDHE-RSA-AES128-GCM-SHA256

See testssl.sh/openssl-iana.mapping.html for the mapping.

Hi Jeffrey.  Thanks very much for that especially the mapping sheet.

However, even with the name ECDHE-RSA-AES128-GCM-SHA256, it does not show up in the list of supported ciphers:

docs.progress.com/.../Supported-protocols-ciphers-and-certificates-for-Progress-OpenEdge-clients-and-servers.html

I can get the environment variables set and do further testing, but I just wanted to check that my understanding was correct that Progress does not support the above cipher from a standard OpenEdge client based on the list.  And thus, even if I get something to work, its not really supported.

I don't if this is an option, but you may want to consider using Apache as a forwarding proxy and thus let Apache handle the secure connection to the other end. This way you can connect to your (local) Apache with http if you want (or whatever protocol is supported) and Apache forwards it.

Thanks bronco.  I've been looking at this and the IIS forwarding proxy option also.  I don't know what and if there are downsides and how easy to configure.

The other alternative I've been considering is to do REST calls with an alternative client, e.g. C#, and find some way to integrate the results.

I'd much rather that everything was seamless in the next incremental upgrade of Progress, but looking at the WSDL/bprowsdl support for web services where there are equally still lots of problems that haven't been resolved such as some code pages and the bprowsdldoc not being able to get past some Go Daddy certificates or not being able to parse the WSDL, using Progress technology might not be the best way forwards.

Well, the reason the ciphers are not supported is because they are considered weak. It's unlikely that support will be added (IMHO).

Hi Bronco.  Thanks for that.  Whilst that makes sense for any services being created on the Progress-side, it doesn't make sense for calling stuff in the wild.  The weak considation comes later after a weakness has been found.  Otherwise, nothnig will ever get supported.  It's about supporting it and later depracating it as pretty much all other technologies do.

Hello,

I'm facing a similar issue connecting to an external SOAP API. this was working fine until several days ago. Unfortunately we are not finding the issue. We are running  11.7.5 on Linux.

When connecting to the endpoint (CONNECT in ABL), i'm getting this error:

11:16:22   Secure Socket Layer (SSL) failure. error code 336151568:  SSL routines (9318)
11:16:22   Connection failure for host ws.newyse.com port 443 transport HTTPS. (9407)
11:16:22   Error loading WSDL document  Fatal Error: connect operation failed (Success) (11748)

So for some reason the SSL handshake is not working.

Using this command the SSL connection seems fine:

$proenv> sslc s_client -connect url.to.api:443 -CApath $DLC/certs

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5386 bytes and written 410 bytes
Verification: OK

Without explicitly setting the -CApath to $DLC/certs i'm getting an error:

$proenv> sslc s_client -connect url.to.api:443

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5386 bytes and written 410 bytes
Verification error: self signed certificate in certificate chain

Has anyone have some idea on how to debug this issue?

also set the logging to "5" and got this:

[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x00000000 BIO-0x00000000 INFO --- Initialized OpenSSL client logging
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x00000000 BIO-0x00000000 INFO --- Enabling SSL Client session reuse
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x00000000 BIO-0x00000000 INFO --- Set SSL Client CipherSuites: AES256-GCM-SHA384
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x00000000 BIO-0x00000000 INFO --- Set SSL Client Protocols: TLSv1.2
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x00000000 INFO --- SSL Client starting handshake with host (url.to.api)
[Thu Aug 29 11:16:22 2019] INTERNAL STATE OPERATION --- SSL State: 16 before SSL initialization
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- ctrl to 03070B50 [03070ED0] (6 bytes => 0 (0x0))

[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- contents of a BIO dump:
[Thu Aug 29 11:16:22 2019] INTERNAL STATE OPERATION --- SSL_connect:before SSL initialization
>>> ??? [length 0005]
16 03 01 00 89
>>> ??? [length 0089]
01 00 00 85 03 03 9d 95 32 2b b6 cf 7f 05 8a 1b
c6 59 dd 18 7d b8 95 36 63 ee 2b fc 0c 79 da 48
0b 23 38 61 d0 6e 00 00 04 00 9d 00 ff 01 00 00
58 00 0b 00 04 03 00 01 02 00 0a 00 0c 00 0a 00
1d 00 17 00 1e 00 19 00 18 00 23 00 00 00 16 00
00 00 17 00 00 00 0d 00 30 00 2e 04 03 05 03 06
03 08 07 08 08 08 09 08 0a 08 0b 08 04 08 05 08
06 04 01 05 01 06 01 03 03 02 03 03 01 02 01 03
02 02 02 04 02 05 02 06 02
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- write to 03070B50 [0318D3B0] (142 bytes => 142 (0x8E))

[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- contents of a BIO dump:
0000 - 16 03 01 00 89 01 00 00-85 03 03 9d 95 32 2b b6 .............2+.
0010 - cf 7f 05 8a 1b c6 59 dd-18 7d b8 95 36 63 ee 2b ......Y..}..6c.+
0020 - fc 0c 79 da 48 0b 23 38-61 d0 6e 00 00 04 00 9d ..y.H.#8a.n.....
0030 - 00 ff 01 00 00 58 00 0b-00 04 03 00 01 02 00 0a .....X..........
0040 - 00 0c 00 0a 00 1d 00 17-00 1e 00 19 00 18 00 23 ...............#
0050 - 00 00 00 16 00 00 00 17-00 00 00 0d 00 30 00 2e .............0..
0060 - 04 03 05 03 06 03 08 07-08 08 08 09 08 0a 08 0b ................
0070 - 08 04 08 05 08 06 04 01-05 01 06 01 03 03 02 03 ................
0080 - 03 01 02 01 03 02 02 02-04 02 05 02 06 02 ..............
[Thu Aug 29 11:16:22 2019] INTERNAL STATE OPERATION --- SSL_connect:/TLS write client hello
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- read to 03070B50 [031841F3] (5 bytes => 5 (0x5))

[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- contents of a BIO dump:
0000 - 15 03 03 00 02 .....
<<< ??? [length 0005]
15 03 03 00 02
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- read to 03070B50 [031841F8] (2 bytes => 2 (0x2))

[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- contents of a BIO dump:
0000 - 02 28 .(
<<< ??? [length 0002]
02 28
[Thu Aug 29 11:16:22 2019] INTERNAL STATE OPERATION --- read:fatal:handshake failure
[Thu Aug 29 11:16:22 2019] INTERNAL STATE OPERATION --- SSL_connect:error in error
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 ERROR --- SSL Client handshake failure (336151568) SSL routines
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 INFO --- Terminated SSL Client session
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- ctrl to 03070B50 [03070ED0] (7 bytes => 0 (0x0))
[Thu Aug 29 11:16:22 2019] ID-0x03179610 CTX-0x0317c420 BIO-0x03070b50 BIO --- contents of a BIO dump

Hopefully anybody has an idea on how to solve this.

A fatal handshake error means that one side or the other sent something the other refused to accept.   A thought in this case is the server configuration or TLS stack changed somehow.   It's not showing exactly what the error is from the debug callbacks.

When using s_client, remember it uses a lot of internet defaults - so you may not be using the same protocol or set of cipher suites.   Try using your -CApath test and include '-tls1_2 -debug -msg -state -showcerts'  - this will produce output similar to what you get from the ABL so they can be compared.   This might produce more information to track down what is different.

Good luck!

Thanx for the suggestion Michael. I did so, but it did not really help me much, but it gave me the direction to find my solution:

I needed to add the full certificate chain to the $DLC/certs dir (with the certutil -import ... tool).

i had to active the TLSv1.2 SHA384  ciphers:

TLSv1.2

AES256-GCM-SHA384

DHE-RSA-AES256-GCM-SHA384

ADH-AES256-GCM-SHA384

The default server certificate must be signed with SHA384.

Do the following for server certificates:

1. Take a backup of $DLC/keys/default_server.pem (that is signed with SHA256)

2. Rename $DLC/keys/test_server_SHA384.pem to $DLC/keys/default_server.pem.

and i needed to use some specific extra variables to the connect method in abl:

-sslprotocols TLSv1.2 -sslciphers ECDHE-RSA-AES256-GCM-SHA384 -servername 'url.to.api'

see reference for -servername:

knowledgebase.progress.com/.../The-ABL-client-does-not-support-an-SNI-enabled-Web-Service

just wanted to post this here for people that have the same issues.

Hi Bronco, I've looked into the forward proxy / reverse proxy options.  Have you got it working before?  From what I can tell, forward proxies can do a redirect but still require the source client to initiate the SSL handshake.  Reverse proxies have something called SSL offloading, but this cannot initiate HTTP to HTTPS, more rather for clients that some inbound over HTTPS to terminate at the proxy for the rest of the journey to the server to be HTTP - so it can terminate a HTTPS transmission but the proxy cannot initiate one from a HTTP call as far as i can tell.

So this leaves one option I want to check.  If I write some c# code to call the REST SSL endpoint and get it working.  If I then try and create a library and get Progress to call it, will it still work, or is there something in the Progress ABL client that places limits somewhere such that it won't work?  Thanks.

<VirtualHost *:8087>

 SSLProxyEngine on

 SSLProxyCheckPeerCN off

 SSLProxyCheckPeerName off

 SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

 SSLProxyCipherSuite ALL:!EDH:!DHE:!ECDHE:!ECDH:!ADH:RC4+RSA:!EDH:+HIGH:+MEDIUM:+LOW:!SSLv2:!3DES:!DES:+EXP

 # LimitRequestFieldSize 16380

 ProxyRequests On

 ProxyVia On

 ProxyRemote * http://<transparent-proxy-server>:8080

 <Proxy "*">

ProxyAddHeaders off

ProxyPreserveHost on

   AddDefaultCharSet off

   Require all granted

   Require local

 </Proxy>

 #ErrorLog ${APACHE_LOG_DIR}/error_forward_proxy.log

 #CustomLog ${APACHE_LOG_DIR}/access_forward_proxy.log combined

 ErrorLog d:/opt/apache24/logs/error_forward_proxy.log

 CustomLog d:/opt/apache24/logs/access_forward_proxy.log combined

</VirtualHost>

This what I used to negotiate an transparant proxy, which implies that the handshake is done by Apache (iirc).

Thanks bronco - I'll give it a go.