curl and certificate verification in jessie
ghedo at debian.org
Mon Dec 1 18:50:25 UTC 2014
On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote:
> > > 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?
If you are asking if curl is gonna go back to gnutls26, I don't think that's
gonna happen. AFAICT it's not maintained upstream anymore and gnutls28 provides
stuff like ECC support that's IMO more important.
As for fixing it, you need to discuss this with the gnutls maintainers.
> We consider it a security-related regression compared to wheezy and while we
> could run private builds of the code on debian.org, that'd be pretty silly
> (and a waste of manpower).
What does "security-related regression" mean? (if anything this makes security
checks tighter). The problem, I think, is that you provide curl (and thus
gnutls) with a CA certificate that doesn't actually sign the end certificate of
the site you are trying to connect to (even if the two are the same
Again, I don't know if this is intended or not, you need to talk with the gnutls
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the Pkg-gnutls-maint