Certificate issue during coverity build

#1

Seems there is some regression with the coverity, apparently while downloading the tools:

Coverity Scan analysis selected for branch coverity_scan.
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
/home/travis/.rvm/rubies/ruby-2.5.3/lib/ruby/2.5.0/json/common.rb:156:in `parse': 765: unexpected token at '' (JSON::ParserError)
	from /home/travis/.rvm/rubies/ruby-2.5.3/lib/ruby/2.5.0/json/common.rb:156:in `parse'
	from /home/travis/.rvm/rubies/ruby-2.5.3/lib/ruby/2.5.0/json/common.rb:15:in `[]'
	from -e:1:in `<main>'
/home/travis/.rvm/rubies/ruby-2.5.3/lib/ruby/2.5.0/json/common.rb:156:in `parse': 765: unexpected token at '' (JSON::ParserError)
	from /home/travis/.rvm/rubies/ruby-2.5.3/lib/ruby/2.5.0/json/common.rb:156:in `parse'
	from /home/travis/.rvm/rubies/ruby-2.5.3/lib/ruby/2.5.0/json/common.rb:15:in `[]'
	from -e:1:in `<main>'
Coverity Scan analysis NOT authori

See https://travis-ci.org/siemens/jailhouse/builds/522747432.

Is this a known issue? The fact that makes me believe it’s a regression is that I didn’t change anything in our build between the last version that succeeded.

Curl: (60) SSL certificate problem: unable to get local issuer certificate
Curl: (60) SSL certificate problem: unable to get local issuer certificate
#2

This is a problem with scan.coverity.com. Report it to them.


There is only one curl command in your codebase: curl -s https://scan.coverity.com/scripts/travisci_build_coverity_scan.sh -o ci/travisci_build_coverity_scan.sh.orig And running it locally does reproduce the error.

It turns out, the certificate chain sent by scan.coverity.com doesn’t include intermediate authority certificate – for “Entrust Certification Authority - L1K”. Which is required per the TLS standard.

So if that certificate is not present locally, verification will fail. Indeed, Xenial’s store only includes the root certificate, “Entrust Root Certification Authority - G2”, with which the L1K one is signed.

I can verify that scan.coverity.com opens in Win64 Firefox 66 because its store includes the intermediate certificate but not in Xenial’s Firefox 66 'cuz its store doesn’t.


In the meantime, you can download the L1K certificate and pass it to curl manually:

curl -L https://entrust.com/root-certificates/entrust_l1k.cer -o l1k.crt
curl --cacert l1k.crt https://scan.coverity.com/<etc>
1 Like
#3

Oh, completely forgot my own workaround in that script! Thanks for analyzing in such details and the workaround proposal. It didn’t work as-is, but adding this did the trick:

curl -s -L https://entrust.com/root-certificates/entrust_l1k.cer | \
    sudo tee -a /etc/ssl/certs/ca-certificates.crt

I found a corresponding report on the coverity forum and will try to link and report that way. Not very optimistic seeing a quick fix, though. They seem to have major IT issues.

#4

Took more than that because, after fixing my own script /wrt curt, travis’ own coverity binding stumbled while using wget for downloading the tools. I now add the missing cert to the local storage:

sudo curl -s -L https://entrust.com/root-certificates/entrust_l1k.cer -o /usr/local/share/ca-certificates/entrust_l1k.crt
sudo update-ca-certificates
2 Likes
#5

Thank you so much for investigating this one and providing a workaround. We’ll be looking at patching this at the product level but we don’t have an ETA at this time when it will happen.

I’m also adding a workaround for macOS:

before_install:
      - curl -Ls https://entrust.com/root-certificates/entrust_l1k.cer -o ~/entrust_l1k.crt || exit 1
      - curl -LS https://curl.haxx.se/ca/cacert.pem -o ~/cacert.pem || exit 1
      - cat ~/entrust_l1k.crt >> ~/cacert.pem || exit 1
      - echo "cacert=\"$HOME/cacert.pem\"" > ~/.curlrc || exit 1
      - echo "ca_certificate=$HOME/cacert.pem" > ~/.wgetrc || exit 1
#6

I suggest you urge Coverity to fix the issue at the same time. An official inquiry from you about a major problem with their service is something that they will probably give priority handling.

#7
#8

According to https://travis-ci.org/native-api/test_travis/builds/526230919 (Linux jobs hang for that one) and https://travis-ci.org/native-api/test_travis/builds/526233375 , the missing certificate issue at scan.coverity.com has been resolved.

closed #9
#10

Closing this for now. If the problem recurs in the future, please open a new topic, referring to this one.