Blog dedicated to Oracle Applications (E-Business Suite) Technology; covers Apps Architecture, Administration and third party bolt-ons to Apps

Wednesday, July 26, 2017

Unable to locally verify the issuer's authority

Chuka pinged me when he got this error in Qualys logs after installation of qualys agent on a server

2017-07-24 15:23:08.497 [qualys-cloud-agent][232147]:[Information]:Finished curl request
2017-07-24 15:23:08.497 [qualys-cloud-agent][232147]:[Error]:Http request failed:Peer certificate cannot be authenticated with given CA certificates: SSL certificate problem: unable to get local issuer certificate
2017-07-24 15:23:08.497 [qualys-cloud-agent][232147]:[Error]:Http request failed: error code: 0
2017-07-24 15:23:08.497 [qualys-cloud-agent][232147]:[Error]:CAPI request failed:
2017-07-24 15:23:08.497 [qualys-cloud-agent][232147]:[Error]:CAPI event failed

2017-07-24 15:23:08.500 [qualys-cloud-agent][232147]:[Information]:Next event: INTERVAL_EVENT_CAPI, time left: 100 seconds

I suggested that we try setting http_proxy and https_proxy environment variables and check with wget and curl

We did that and got the error:

Unable to locally verify the issuer's authority

On, I found that described a similar issue on RHEL5, we are on OEL6:

Getting "Unable to locally verify the issuer's authority" error from wget in RHEL 5



  • Red Hat Enterprise Linux (RHEL) 5.5


  • When downloading from certain SSL URLs, wget throws the error "Unable to locally verify the issuer's authority".


Root Cause

  • The openssl /etc/pki/tls/certs/ca-bundle.crt file in RHEL 5.5 is outdated.

Diagnostic Steps

Reproduction steps:

$ wget
--2010-07-24 15:30:14--
Resolving, 2001:4178:2:10::54, 2001:4178:2:10::55, ...
Connecting to||:443... connected.
ERROR: cannot verify's certificate, issued by '/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA':
  Unable to locally verify the issuer's authority.
To connect to insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
So we compared the size of the file  /etc/ssl/certs/ca-certificates.crt on a working server and this server.  Sure enough the file size was different.  On further investigation we found that there was a backup called ca-bundle.crt.newrpm that had the correct size.  So we took a backup of ca-bundle.crt and replaced it with the newer file.  The error stopped coming.  Even though the ca-certificates rpm version was same on both servers, someone had replaced the ca-bundle.crt file with the older version.  We would have to investigate, why that was done, before this solution can be implemented, as it is possible that the new certificates.crt file broke something, because of which it was replaced by the older version.  We should always have the latest ca-bundle.crt, so that we have the latest root certificates from the Certificate Authorities.

No comments: