CS 21.3 RestClient SSL Certificate issue

I am using RestClient to call external RestAPI and run into below error:

SSL Exception: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

The thread debug log:

01/03/2022 12:28:39 DEBUG new restclientSecure: host api.smartsheet.com port 443 uri /2.0/users/me

01/03/2022 12:28:39 DEBUG restclient: send GET request, no content

01/03/2022 12:28:39 DEBUG restclient: Invalid Certificate: unable to get local issuer certificate errnum=20

SubjectName=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2IssuerName=/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority

01/03/2022 12:28:39 DEBUG restclient: finish request threw exception 0 message SSL Exception: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed


The API being called is Smartsheet API, which is hosted on AWS I believe.

The same code works on CS16.2.11. What I need to do to make it still working on CS 21.3?

Tagged:

Comments

  • looks like a SSL Cert error, I would try the same call with another tool, e.g. CURL/PostMan etc to rule out OT being in the loop and then investigate the error returned as Google has many results for the message - https://lmgtfy.app/?q=unable+to+get+local+issuer+certificate

  • Hi dluo - when you say "The same code works on CS16.2.11" : is your 16.2.11 installation on the same PC?

    Why I ask: this looks to be a generic certificate trust issue (as per @Greg Griffiths' comment). Could you see if the cert mentioned above is known to that PC? To do this:

    1. Select Run from the Start menu, and then enter certlm.msc.
    2. To view the certificates, under Certificates - Local Computer in the left pane, expand the directory for Trusted Root Certificate Authority and then Certificates.

    Thx 🙂

    @siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you

  • @Dave Carpeneto , No, they are not on the same computer. CS16 is installed in my local dev box, CS21 is the client machine.

    So based on the thread log, "Starfield Services Root Certificate Authority - G2" seems to be the CA missing. 3 Starfield CAs similar to that are found in system store but do not match the name exactly.

    Then CS21 is running on TomCat Web server, which also has some SSL configuration. Not sure if this should be the correct place to check the certificates.


  • 3 Starfield CAs similar to that are found in system store but do not match the name exactly.

    Being close only counts in darts 😉

    Not sure if this should be the correct place to check the certificates.

    I'm not sure either, but regardless: this very much looks to be an operational issue relating to certificate management. Unfortunately I'm not an expert on this, but usually google-ing about will result in a solution 🙂

    @siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you

  • Since you are calling the service on HTTPS meaning your RESTClient through Livelink is just performing what another tool like CURL or POSTman do I wouldn't think Tomcat will be involved in this. What I would try is to use your browser or postman to call that external service. If it is successful Postman is going to store the certificate where it needs to do. Having that certs on Tomcat allow someone else calling your livelink to have a trusted path the other way around if a developer wanted to use your livelink's restapi. You should then try to see if putting that cert in where OT's java programs like OTDS and other java libraries exist I think you might find them if not mistaken in

    see the last poster's comment https://forums.opentext.com/forums/support/discussion/300237/in-place-upgrade-from-content-server-16-2-6-to-20-2#latest


    You also probably can for testing create a non https connector on the other service and see if the RESTclient code itself work or not just to be sure.


    your message  this one "1/03/2022 12:28:39 DEBUG restclient: finish request threw exception 0 message SSL Exception: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed" is akin to the other poster's see "Error: Error validating a ticket. Error 0: SSL Exception: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed."
    


  • Yes, Tomcat is not related. CS21 is actually using IIS, but OTDS is using Tomcat. The certs on Tomcat allows Content Server to call the OTDS service ( both CS and OTDS are on https).

    My colleague fixed the issue. He imported the root to root certificates, and the 4 intermediates to the intermediate certificates into windows trust store, then restarted Content Server and IIS.

    I am not clear what are these certificates though.

    As a side note, based on KB17692595, starting from CS20.3, RestClient needs to verify the certificate of external RestAPI in https. That explains why it is working fine in my CS16 setup.

    https://knowledge.opentext.com/knowledge/llisapi.dll/kcs/kbarticle/view/KB17692595

  • starting from CS20.3, RestClient needs to verify the certificate

    Ha! Good to know / apologies for not knowing of that (I've made use of the REST client, but I don't work on that bit of Content Server). Thank you for flagging this 🙂

    @siegel: vi is an editor with two modes: one which destroys your input and the other which beeps at you

  • I was running into some similar issues with an API endpoint. I tried out the URL in FF and it worked. I access the endpoint with Apache HttpClient, no problem. Stick the URL into Chrome, and it comes back as insecure. Chrome not terribly informative as to why it considers the URL endpoint insecure though.

    -Hugh

  • Hey Guys,

    Chrome requires special consideration for the SSL Certificate. You need to make sure you populate the Subject Alternative Name


    If this isn't populated, chrome will not like it.

    @dluo
    If you are using self signed certificates, you need to update the cacerts file in the JRE/JDK.
    Java cares not for the Windows Certificate store/Windows Trusted Certificates. Java processes are independent of the Windows Certificate Store.

    Regards,
    -MC