FS#39453 - [openssl] 1.0.1.f-2 breaks curl and bzr.

Attached to Project: Arch Linux
Opened by Frederic Bezies (fredbezies) - Saturday, 15 March 2014, 14:33 GMT
Last edited by Pierre Schmitz (Pierre) - Saturday, 10 May 2014, 07:51 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: I wanted to build kazam-bzr from AUR, and when bzr tried to connect to source repository, I got this error message :

==> Connecting to Bazaar server....

See `bzr help ssl.ca_certs` for how to specify trusted CAcertificates.
Pass -Ossl.cert_reqs=none to disable certificate verification entirely.

bzr: ERROR: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

So, I tried with kazam, and curl gave me this error :

curl: (60) SSL certificate problem: self signed certificate in certificate chain
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.

Additional info:
OpenSSL 1.0.1.f-2

Steps to reproduce: Just install last OpenSSL from testing.

Rebuilding curl doesn't fix the bug.
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Saturday, 10 May 2014, 07:51 GMT
Reason for closing:  Not a bug
Comment by Frederic Bezies (fredbezies) - Saturday, 15 March 2014, 15:22 GMT
Forget to add : it only happens when secured connections are needed. Which is annoying if you want to test or install bzr or git versions of software.
Comment by Pierre Schmitz (Pierre) - Saturday, 15 March 2014, 15:48 GMT
Looks like a server configuration problem to me. It does not seem to be related to the openssl package (downgrading to the version from [core] does not chagne anything here).

Errors like this usually happen when you don't send the complet certificate chain or one of the certs is invalid.

Update: Downgrading ca-certificates "solves" the issue. The "validcert" certifiates launchpad uses are removed from the cert bundles as they are probably weak and insecure. See http://packages.qa.debian.org/c/ca-certificates/news/20140313T130323Z.html

I suggest reporting this to Canonical.
Comment by Adam Reichold (adamreichold) - Tuesday, 25 March 2014, 18:03 GMT
Reported it to Launchpad and their response was:

ur certificate chain was fine, and should have been accepted even by
browsers with the ValiCert root removed. We were sending the GoDaddy
root cross-signed by ValiCert from back when the GoDaddy cert wasn't
directly trusted by browsers. But it seems that NSS and OpenSSL fail to
stop validating the chain when they reach a trust anchor, instead
requiring that the entire chain be trusted. This is going to become a
significant problem as common old weak roots are revoked, and their
still-valid intermediates are considered invalid by browsers.

But we've worked around this client misbehaviour for now by removing the
ValiCert root from our chain, so browsers without the ValiCert root
should function again.

So I suppose it should work now.
Comment by Frederic Bezies (fredbezies) - Wednesday, 26 March 2014, 08:15 GMT
Indeed it works back now. So, this bug can be closed. I was "unlucky" :)

Loading...