Secure Socket Layer (SSL) failure. error code -54: self sig

Posted by aswanson19 on 07-Jun-2019 16:46

Hello!

I'm having trouble with sending a POST request to the UPS tracking API using the IHttpClient. I get the following error when executing the request in ABL Scratchpad:

"Secure Socket Layer (SSL) failure. error code -54:  self signed certificate in certificate chain: for 157753a5.0 in C:\Progress\OpenEdge116\certs (9318)"

I have tried the solutions from these knowledgebase articles:

https://knowledgebase.progress.com/articles/Article/P136334

https://knowledgebase.progress.com/articles/Article/000048772

https://community.progress.com/community_groups/openedge_development/f/19/t/55829

It appears to be an issue with a missing certificate. I tried downloading the root certificate and importing it with the "mkhashfile" command, but nothing has solved this error. None of the certificates I've imported have had the same name as the one in the error message (157753a5.0). I suspect it is looking for a certificate file with that name but can't find it.

I was able to send a POST request like this to XPO's API without issue.

Here is my code:

USING Progress.Lang.* FROM PROPATH.
USING Progress.Json.ObjectModel.* FROM PROPATH.
USING Spark.Core.Service.DynamicEntity FROM PROPATH.
USING Spark.Core.Util.ApplicationError FROM PROPATH.
USING OpenEdge.Core.String.
USING OpenEdge.Net.HTTP.ClientBuilder.
USING OpenEdge.Net.HTTP.Credentials.
USING OpenEdge.Net.HTTP.IHttpClient.
USING OpenEdge.Net.HTTP.IHttpRequest.
USING OpenEdge.Net.HTTP.RequestBuilder.
USING OpenEdge.Net.URI.
USING OpenEdge.Net.HTTP.IHttpResponse.
USING Progress.Json.ObjectModel.JsonObject.

DEFINE VARIABLE oHttpRequest AS IHttpRequest  NO-UNDO.
DEFINE VARIABLE oResponse    AS IHttpResponse NO-UNDO.
DEFINE VARIABLE oUri         AS URI           NO-UNDO.
DEFINE VARIABLE oClient      AS IHttpClient   NO-UNDO.
DEFINE VARIABLE oJsonEntity  AS JsonObject    NO-UNDO.
DEFINE VARIABLE oJsonBody    AS JsonObject    NO-UNDO.

oJsonEntity = NEW JsonObject().
oJsonBody = NEW JsonObject().
    
oClient = ClientBuilder:Build():Client.
    
oUri = NEW URI('https', 'upsfreight.com').
oUri:Path = '/shipping/Tracking/Index.aspx'.
    
// Build JSON body
//
Code for building the
POST request JSON body goes here oJsonBody:Add("Username", "exampleuser").
...
// Send request oHttpRequest = RequestBuilder :Post(oUri, oJsonBody) :ContentType('application/json') :AcceptJson() :Request. oResponse = oClient:Execute(oHttpRequest). IF TYPE-OF(oResponse:Entity, JsonObject) THEN ASSIGN oJsonEntity = CAST(oResponse:Entity, JsonObject).

 

Any help is appreciated.

 

Thanks!

Posted by Jeffrey Z. Wolf on 10-Jun-2019 18:49

I just got it to work on 11.6.

When I first pulled down all of the certs from the upsfreight site and installed same and ran your code, I got the following error:

Secure socket layer(SSL) failure code -55 Connect hostname (upsfrieght.com) does ont match certificate: www.upsfreight.com connections failure.....

I noticed that in your code you have

oUri = NEW URI('https', 'upsfreight.com').

That rang a bell for me relative to the error message.

I changed your code to the following:

oUri = NEW URI('https', 'www.upsfreight.com'). and it worked. I got a successful wirteshark trace and the return code was 200/OK.

(Notice the addition of the "www" to the host name)

I can not tell you why this is not required in 11.7.4 but is in 11.6. It may have to do with the lack of wildcard support in 11.6.

All Replies

Posted by Jeffrey Z. Wolf on 07-Jun-2019 20:21

Hello.

I just ran your code and got a 200/OK.

You'll need to go to this site secure.comodo.com/.../publiclyDisclosedSubCACerts and get the Comodo RSA Certification Authority certificate. This seems to be an issuing authority certificate not on the UPS site.

Thus I loaded the certificate chain from the UPS site AND I had to load this root of roots certificate from the web site above.

Use certutil -verbose -display on the certificates you get from the UPS site. Look for the issuer for the certificate. Then I used that information to go to the root issuer site and found a certificate the was similar in name to that referenced in the root certificate from the UPS site.

I hope this helps.

Posted by aswanson19 on 10-Jun-2019 13:17

Hi Jeffrey,

I loaded the Comodo RSA Certification Authority certificate from the site you gave, but I get the same error. 

Here's a screenshot of the certificates from UPS that I've imported. The details of that top cert from Sectigo (formerly Comodo CA) is on the right. It seems to be the same certificate as the one you described above. When I run certutil -verbose -display on both certificates, they show the same information. 

Am I loading these incorrectly? I downloaded the certs in PEM format, Base64 encoded, and then imported them with the certutil -import "C:\cert\path" command. Starting with the bottom cert and working up, it generated db9b9ca8.0 (upsfreight.com), c43a77d9.0 (COMODO RSA Organization Validation), and d6325660.0 (Sectigo / Comodo RSA Certification Authority) in my C:\Progress\OpenEdge116\certs folder. After that I tried running my code again but I get the same error.

Posted by Jeffrey Z. Wolf on 10-Jun-2019 15:45

Hello

I checked the hashed file names that I got when using certutil to plce the certificates into the certs directory.

d6325660.0  ->  db9b9ca8.0 -> c43a77d9.0

Those look the same as what you are getting.

The only other thing I can think of is what OpenEdge version are you running? I am running 11.7.4. If you are running something substantially older, that might some into play.

Posted by Tim Hutchens on 10-Jun-2019 16:14

It doesn't look like this is the problem you're having with this specific website, but I did want to mention that wildcard certificates were not supported until OpenEdge 11.7. But that would be if the certificate was for "*.upsfreight.com". You're screenshot shows "www.upsfreight.com". The wildcard certificate issue in 11.6 and below would throw the same error you are getting though. The temporary solution was to access the API via HTTP instead of HTTPS as a workaround until we upgraded to 11.7.

Tim

Posted by aswanson19 on 10-Jun-2019 16:15

I'm on 11.6

Posted by aswanson19 on 10-Jun-2019 16:15

I'm on 11.6

Posted by aswanson19 on 10-Jun-2019 17:03

Hi Tim,

I had heard about the wildcard certificate issue before. I didn't think it applied in this case since the certificate shows "www.upsfreight.com" like you mentioned. However, since Jeffrey was able to get a successful response on using 11.7.4 while I'm on 11.6, this may be the issue. The problem with using the HTTP workaround is that the UPS API only works with HTTPS. I will test on 11.7 and see if I run into the same problem.

Posted by gus bjorklund on 10-Jun-2019 17:16

> On Jun 10, 2019, at 9:25 AM, aswanson19 wrote:

>

> I tried running my code again but I get the same error.

and the error you get is that it thinks the comodo/sectigo cert is a self-signed certificate. so your session does not know comodo is a ca. maybe what you need to do is to add comodo as a known root CA. sorry but i have no idea how that is done.=

Posted by aswanson19 on 10-Jun-2019 18:43

It worked after using version 11.7 and importing the certificates again. It must have been a wildcard cert, or there was something in 11.6 that broke it.

Thank you all for the help!

Posted by Jeffrey Z. Wolf on 10-Jun-2019 18:49

I just got it to work on 11.6.

When I first pulled down all of the certs from the upsfreight site and installed same and ran your code, I got the following error:

Secure socket layer(SSL) failure code -55 Connect hostname (upsfrieght.com) does ont match certificate: www.upsfreight.com connections failure.....

I noticed that in your code you have

oUri = NEW URI('https', 'upsfreight.com').

That rang a bell for me relative to the error message.

I changed your code to the following:

oUri = NEW URI('https', 'www.upsfreight.com'). and it worked. I got a successful wirteshark trace and the return code was 200/OK.

(Notice the addition of the "www" to the host name)

I can not tell you why this is not required in 11.7.4 but is in 11.6. It may have to do with the lack of wildcard support in 11.6.

Posted by Jeffrey Z. Wolf on 10-Jun-2019 18:51

In your code, I changed

"oUri = NEW URI('https', 'upsfreight.com')."

to

oUri = NEW URI('https', 'www.upsfreight.com').

and it worked, on 11.6, after installing all certificates.

I am not sure why but it may relate to the lack of wildcard certs back in 11.6

Posted by Jeffrey Z. Wolf on 10-Jun-2019 18:52

I got a response of 200/OK and a wireshark trace showed the full transfer.

Posted by aswanson19 on 10-Jun-2019 19:22

Very strange. Even when I add the "www" to it and reinstall the certs, I get the " -54 self signed certificate in certificate chain" error. I've never gotten the "-55 Connect hostname does not match certificate" error, but it would make sense. I don't know why it is still complaining about the self-signed certificate for me though.

Posted by Jeffrey Z. Wolf on 10-Jun-2019 19:41

I re-pulled down the certificates from the upsfreight site for testing on 11.6

The hashes for the root and the lowest level certificates were the same.

The certficate in the middle gave me a different hash as follows

(root) d6325660.0 -> (intermediate) 157753a5.0 -> c43a77d9.0

Posted by aswanson19 on 10-Jun-2019 20:12

Interesting. Your intermediate certificate is the one I don't have. I still get d6325660.0 as root (Sectigo), c43a77d9.0 as the middle (COMODO RSA Organization Validation), and db9b9ca8.0 for www.upsfreight.com. Are you downloading them through the certificate window (like the screenshot above)? That's what I'm using.

Posted by Jeffrey Z. Wolf on 10-Jun-2019 20:28

Hello

I went to this site:

www.upsfreight.com/.../

I clicked on the padlock, to the left of the URL

I clicked certificate

I went through the Certificate path tab and "copied to file" each of the certificates ensuring that I output them in base64 encoding.

Then certutil -import <certificate>

Posted by aswanson19 on 11-Jun-2019 12:19

That's the process I'm using too. Not sure how I'm getting a different certificate.

Here's my proenv output from importing the certs, with 1 being the lowest and 3 being the root cert.

Posted by aswanson19 on 11-Jun-2019 16:15

Can you send the certificate you got for 157753a5.0? Once I import it, I should be able to get this working like you did.

Posted by Jeffrey Z. Wolf on 11-Jun-2019 20:15

Hello

I'd need your email address.

This thread is closed