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.
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.
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.
Quick update.
I just ran my connect code with no problems under OpenEdge11x so it does look like a Progress version issue.
Mark.
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!
I'm guessing there's no way round this issue (in 10.2A) other than updating to OE 11 x?
Thanks,
Mark.
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.
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.
Using STunnel as a proxy server is another option.
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
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
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.
No you can use it for web services too.
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.
Agreed, I tried this with no difference to the error...