curl and certificate verification in jessie

Tollef Fog Heen tfheen at
Mon Dec 1 10:18:19 UTC 2014

]] Alessandro Ghedini 

> On sab, nov 29, 2014 at 01:10:20 +0100, Peter Palfrader wrote:
> > I recently started to move parts of's infrastructure to jessie.  I
> > noticed a regression with software using curl to do https with certificate
> > verification.
> > 
> > On wheezy, this works:
> > 
> > | weasel at mipsel-manda-01:~$ cat /etc/apt/apt.conf.d/puppet-https-buildd
> > | "/etc/ssl/servicecerts/";
> > | weasel at mipsel-manda-01:~$ tail -n1 /etc/apt/sources.list.d/
> > | deb  wheezy  main
> > 
> > I.e., I can use a local copy of the expected end-entity certificate to
> > authenticate a https server.
> > 
> > On jessie this no longer works:
> > 
> > } Err wheezy/main mipsel Packages
> > }   server certificate verification failed. CAfile: /etc/ssl/servicecerts/ CRLfile: none
> I assume that this is using apt-transport-https, which in turn uses
> libcurl3-gnutls.

Yes.  We're seeing the same problem when verifying HTTPS urls with git,
which uses curl under the hood.  Presumably other software using
curl/gnutls has the same problem.

> > Is this intentional, or is that a bug in either gnutls, curl, or the software
> > using these libraries?
> AFAICT this is due to the gnutls26 -> gnutls28 switch. Using libgnutls-dev to
> build curl instead of libgnutls28-dev makes it possible to point CURLOPT_CAINFO
> to a single leaf certificate and have the verification succeed.
> FWIW the current behaviour is the same with openssl. I don't know if there's a
> reason for it though.

Can we get it reverted/fixed?  We consider it a security-related
regression compared to wheezy and while we could run private builds of
the code on, that'd be pretty silly (and a waste of
manpower).  Not to mention that gnutls26 isn't even in jessie any more.

Tollef Fog Heen, DSA
UNIX is user friendly, it's just picky about who its friends are

More information about the Pkg-gnutls-maint mailing list