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 access.redhat.com, I found https://access.redhat.com/solutions/37323 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

 SOLUTION VERIFIED - Updated  - 

Environment

  • Red Hat Enterprise Linux (RHEL) 5.5

Issue

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

Resolution

Root Cause

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

Diagnostic Steps

Reproduction steps:

$ wget https://www.internetx.com/
--2010-07-24 15:30:14--  https://www.internetx.com/
Resolving www.internetx.com... 85.236.36.48, 2001:4178:2:10::54, 2001:4178:2:10::55, ...
Connecting to www.internetx.com|85.236.36.48|:443... connected.
ERROR: cannot verify www.internetx.com's certificate, issued by '/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA':
  Unable to locally verify the issuer's authority.
To connect to www.internetx.com 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.

Sunday, July 16, 2017

acroread on Linux 6

As per https://access.redhat.com/errata/RHSA-2013:1402 : Adobe Reader (acroread) allows users to view and print documents in Portable Document Format (PDF). Adobe Reader 9 reached the end of its support cycle on June 26, 2013, and will not receive any more security updates. Future versions of Adobe Acrobat Reader will not be available with Red Hat Enterprise Linux.

Some of our ERPs still use acroread for pasta printing.  When we did the upgrade of OS to OEL 6, we had to reinstall adobe by getting the rpm from adobe site ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/9.5.5/enu/ that I got from https://www.reddit.com/r/linux/comments/2hsgq6/linux_version_of_adobe_reader_no_longer/   Fortunately, adobe still hosts it. It is also available from Red Hat if you have a subscription:

Red Hat Enterprise Linux Server 6

SRPM
x86_64
acroread-9.5.5-1.el6_4.1.i686.rpmSHA-256: ac0934cfe887c6f49238ebff2c963adc33c1531019660bbfa4f8852d725136a2Download
acroread-plugin-9.5.5-1.el6_4.1.i686.rpmSHA-256: 8116e41e4825f74478731a7e970482274db5c9d4b9489b9f70ca4e1a278e526bDownload
i386
acroread-9.5.5-1.el6_4.1.i686.rpmSHA-256: ac0934cfe887c6f49238ebff2c963adc33c1531019660bbfa4f8852d725136a2Download
acroread-plugin-9.5.5-1.el6_4.1.i686.rpmSHA-256: 8116e41e4825f74478731a7e970482274db5c9d4b9489b9f70ca4e1a278e526bDownload

After installing the rpm with rpm -ivh AdbeRdr9.5.5-1_i486linux_enu.rpm command, we got dependency error for libxml2.so.  On installing libxml2.so, we got error for other missing dependencies.  So eventually we did yum install AdbeRdr9.5.5-1_i486linux_enu.rpm which installed about 80 rpms that acroread needs to function.

After installation, we kept getting this error:

dirname: missing operand

The post on http://www.linuxquestions.org/questions/slackware-14/error-message-dirname-missing-operand-when-starting-acroread-827012/ recommended a fix:

The issue was fixed by commenting line 529 in the bash script /opt/Adobe/Reader/bin/acrobat

529 #  [ -n "${MozPath}" ] || mozillaPath="`readlink "$MozPath" | xargs dirname`"

The DBAs were getting this error when they used sudo to login as applmgr:

Adobe Reader does not need to be run as a privileged user. Please remove 'sudo' from the beginning of the command

The post on https://forums.freebsd.org/threads/17345/ recommended that we comment line 331,332,333 and 334:

# Do not allow launch using 'sudo'.
#if [ "${ACRO_ALLOW_SUDO+set}" != "set" -a \( "${SUDO_USER+set}" = "set" -o "${SUDO_UID+set}" = "set" -o "${SUDO_GID}" = "set" \) ]; then
# printf "%s\n" "Adobe Reader does not need to be run as a privileged user. Please remove 'sudo' from the beginning of the command."
# exit 1
#fi

That fixed the sudo issue.

I have asked the DBA team to reach out to the Developers to stop using acroread and migrate to an alternative that is natively supported in Linux.  Here's more from Red Hat on their security advisory https://access.redhat.com/errata/RHSA-2013:1402 :

Red Hat advises users to reconsider further use of Adobe Reader for Linux,
as it may contain known, unpatched security issues. Alternative PDF
rendering software, such as Evince and KPDF (part of the kdegraphics
package) in Red Hat Enterprise Linux 5, or Evince and Okular (part of the
kdegraphics package) in Red Hat Enterprise Linux 6, should be
considered. These packages will continue to receive security fixes.
Red Hat will no longer provide security updates to these packages and
recommends that customers not use this application on Red Hat Enterprise
Linux effective immediately.