SSL Certificate Issue?

Posted by MBeynon on 27-Aug-2015 08:05

Hi,

I'm trying to connect to an https URL with:

lvlWSReturn  = hWebService:CONNECT( ipcWSConnectionString ) NO-ERROR.


However, I keep getting these two errors:

Error #1 [Secure Socket Layer (SSL)
 failure. error code -54:  certificate signature failure: for 00673b5b.0 in
 /usr/local/apps/dlc10/certs (9318)]

Error #2 [Connection failure for host
 www.secpay.com port 443 transport HTTPS. (9407)] / Error #3 [Error loading
WSDL document  https://www........?wsdl
       : Fatal Error: connect operation failed (Success) (11748)]


I've done a bit of "Googling" but I'm not sure I fully understand what's going on. The first error is saying there's a certificate signature failure for 00673b5b.0 in the certs folder, but it does not exist there.

According to Progress regarding SSL errors:

"The client who is connecting to the SSL enabled server is required to have a
copy of the issuing Certificate Authority's digital certificate.  If the SSL
enabled server's digital certificate was issued by a public CA such as RSA,
Verisign or  Thawte, this step is easier because Progress ships the Root digital
certificates for these public CAs with its client products.  You will find these
root certificates in the <install-dir>/certs directory.

If you see this error from your Progress client it indicates that it
    cannot find the Root digital certificate that it needs to validate the
    SSL server's digital certificate.
    
         "Secure Socket Layer (SSL) failure. error code -54: unable to
         get local issuer certificate (9318)".

      1. Obtain a copy of a PEM encoded certificate from the Certificate
         Authority.

      2. Copy that PEM file onto the machine where the Progress client
         will run.

      3. On the client machine, run the certutil -import or mkhashfile command
         from the <install-dir>/bin directory.

         This creates a copy of the PEM encoded certificate file from step
         2 as a hashed file name and copies it to the <install-dir>/certs
         directory on the client machine.

         Before running either of these utilities set the DLC (same as
         <install-dir>) environment variable.

         It may be possible to run these utilities in a PROENV shell.  PROENV
         will properly set DLC."

So, do I need to "Obtain a copy of a PEM encoded certificate from the Certificate Authority" or am I barking up the wrong tree with this?.


Thanks,
Mark.

All Replies

Posted by Michael Jacobs on 27-Aug-2015 12:56

Hello Mark,

I believe the clue to your problem is in this fragment of the error message: "certificate signature failure...".

Without the SSL/TLS handshake protocol details, my first thought is that you are running into a problem common to some OpenEdge applications:  some OpenEdge releases do not support SSL server certificates signed by the issuing CA using one of the SHA2 algorithm.

Apparently the public CAs have begun issuing new server certificates signed using an SHA2 algorithm.   It's not always easy to tell if this is the problem or not.

What version of OpenEdge are you running?

Mike J.

Posted by MBeynon on 28-Aug-2015 02:21

Hi Mike,

Thanks for the reply.

We're using 10.2A.02 on Redhat Unix.

I should just mention I've been through the process of importing the security certificates and followed the knowledge base article for certutil -import and the named 00673b5b.0 file is now in my /usr/local/apps/dlc10/certs directory but the error message is the same.

Thanks,

Mark.

Posted by MBeynon on 28-Aug-2015 09:19

Quick update.

I just ran my connect code with no problems under OpenEdge11x so it does look like a Progress version issue.

Mark.

Posted by Michael Jacobs on 28-Aug-2015 12:08

The OE 11.x series of releases included the enablement of the SHA2 hash algorithms in the ABL language.  Enabling SHA2 in the ABL client also enabled support for the SHA2 signed server certificates the CA's have begun issuing.  May not work everywhere, and it does for your use case.

So moving to OE 11 will be your answer?

Thanks for the updates!

Posted by MBeynon on 01-Sep-2015 03:34

I'm guessing there's no way round this issue (in 10.2A) other than updating to OE 11 x?

Thanks,

Mark.

Posted by cSocaciu on 01-Sep-2015 03:55

If upgrade to version 11.x is not an option you can use third party software in order to route the web service you are trying to access to  a SSL connection. We have used for this Sonic MQ server or created a routing service with IIS server. My recommendation is to use Sonic MQ server. Import the SSL certificate there and from the code you will be connecting to se Sonic MQ server.

Posted by MBeynon on 01-Sep-2015 04:19

Thanks for the suggestion. As our client can't currently upgrade to 11 x we may have to implement some sort of re-routing via Soniq MQ or IIS.

Posted by Donicello Lampe on 01-Sep-2015 04:35

Using STunnel as a proxy server is another option.

Posted by jbijker on 03-Sep-2015 05:41

Hi Mark,

You can also try to include "-nohostverify" in the connection string. This will bypass the certificate check.

Note that you are compromising security by doing so.

Regards

Johan

Posted by MBeynon on 03-Sep-2015 05:58

Hi John,

Thanks for the help but as I understand it, -nohostverify in the connection string is solely when connecting to a Progress Appserver? I could be wrong of course!

Mark

Posted by Donicello Lampe on 03-Sep-2015 05:58

The -nohostverify only skips the check which verifies whether the server's hostname is the same as the one in the certificate (CN). So it does not fully bypass the certificate check. Not sure it will help in this case.

Btw, you could also try 10.2B08 if that's an option. I recently heard of a case where 10.2B08 worked in such a situation.

Posted by jbijker on 03-Sep-2015 06:04

No you can use it for web services too.

Posted by Michael Jacobs on 03-Sep-2015 07:40

The -nohostverify can be used with any connection to a SSL/TLS enabled server.   Donicello's description is correct and -nohostverify will not have any effect on the error you are seeing.

Posted by MBeynon on 03-Sep-2015 07:41

Agreed, I tried this with no difference to the error...

This thread is closed