Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 295617

Summary: subversion won't save bad certificates permanently with neon 0.29
Product: Gentoo Linux Reporter: Till Korten <webmaster>
Component: [OLD] DevelopmentAssignee: Arfrever Frehtes Taifersar Arahesis (RETIRED) <arfrever>
Status: RESOLVED FIXED    
Severity: normal CC: galtgendo
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Till Korten 2009-12-04 06:13:50 UTC
with subversion 1.6.6 and neon 0.29, subversion fails to save test certificates

at home I have a test server with a subversion repository set up. everything used to work fine after accepting the certificate permanently. (using the client on the same machine) However, recently subversion keeps asking whether I would like to accept the certificate but won't offer to save the certificate permanently:
 - The certificate hostname does not match.
 - The certificate has expired.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: *.example.net
 - Valid: from Mon, 11 Jun 2007 00:00:00 GMT until Wed, 15 Sep 2010 23:59:59
GMT
 - Issuer: 
 - Fingerprint: d2:d6:76:ee:7c:b1:87:ce:28:6a:0e:eb:c5:03:87:30:cf:1d:a7:b9
(R)eject or accept (t)emporarily?

The "certificate has an unknown error" message is new and the (p)ermanently option is missing.

someone in this mailing list recommended to downgrade neon to 0.28.x which worked:
http://svn.haxx.se/users/archive-2009-11/0126.shtml
maybe neon should be marked ~x86 until this issue is fixed?

Reproducible: Always

Steps to Reproduce:
1.emerge subversion and neon 0.29 (both stable under x86)
2.try to checkout a repository via https with a test certificate (invalid root ca)
3.
Actual Results:  
option to save certificates permanently is missing


Expected Results:  
should offer to save the certificate permanently and not ask any more
Comment 1 Rafał Mużyło 2009-12-04 09:48:06 UTC
Have you tried to check what exactly is
wrong with that cert, i.e. with:
echo | gnutls-cli --print-cert -p 443 dev.int.example.net | certtool -i
Comment 2 Rafał Mużyło 2009-12-04 10:39:42 UTC
...then recheck with
echo | openssl s_client -connect dev.int.example.net:443 -showcerts | certtool -i

Looking at neon changes, the reason is either NE_SSL_BADCHAIN
or NE_SSL_REVOKED (probably the former), which subversion' neon
plugin doesn't ignore like NE_SSL_UNTRUSTED.
Comment 3 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2009-12-04 21:09:26 UTC
Please report this problem to Neon upstream.
http://lists.manyfish.co.uk/mailman/listinfo/neon
Comment 4 Rafał Mużyło 2009-12-04 22:08:52 UTC
Seeing as those are enhancement (they were not implemented
before), I'd say it's more like subversion code needs to be changed
- from clearing as ==NE_SSL_UNTRUSTED (SVN_AUTH_SSL_UNKNOWNCA)
to clearing at !(SVN_AUTH_SSL_NOTYETVALID || SVN_AUTH_SSL_EXPIRED
|| SVN_AUTH_SSL_CNMISMATCH) in case neon implements something more
in the future.
Comment 5 Till Korten 2009-12-06 00:52:43 UTC
(In reply to comment #2)
> ...then recheck with
> echo | openssl s_client -connect dev.int.example.net:443 -showcerts | certtool
> -i
> 
> Looking at neon changes, the reason is either NE_SSL_BADCHAIN
> or NE_SSL_REVOKED (probably the former), which subversion' neon
> plugin doesn't ignore like NE_SSL_UNTRUSTED.
> 
I did the checks you recommended ( although now with neon 0.28.x but that should not matter, right)
The first check (echo | gnutls-cli --print-cert -p 443 dev.int.example.net | certtool -i) returns:
X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 00c5f5b68a49ce7ae5
	Issuer: C=DE,ST=Saxony,L=Dresden,O=Looneys,OU=section,CN=thawn.homeip.net
	Validity:
		Not Before: Sat Nov 07 11:44:09 UTC 2009
		Not After: Sun Nov 07 11:44:09 UTC 2010
	Subject: C=DE,ST=Saxony,L=Dresden,O=Looneys,OU=section,CN=thawn.homeip.net
	Subject Public Key Algorithm: RSA
---- snip
		Exponent (bits 24):
			01:00:01
	Extensions:
		Subject Key Identifier (not critical):
			b39f1e72905bb0dd259882373ad3b6c64fd4d829
		Authority Key Identifier (not critical):
			b39f1e72905bb0dd259882373ad3b6c64fd4d829
		Basic Constraints (not critical):
			Certificate Authority (CA): TRUE
	Signature Algorithm: RSA-SHA
	Signature:

The second check returns:
depth=0 /C=DE/ST=Saxony/L=Dresden/O=Looneys/OU=section/CN=thawn.homeip.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=DE/ST=Saxony/L=Dresden/O=Looneys/OU=section/CN=thawn.homeip.net
verify return:1
DONE
And then the same as above (as far as I can tell).

To me that looks like all is as it should be, since it is a self signed certificate after all.

I did post to the neon mailing list.

should I also file a bug with subversion or could you do that  Rafał? It seems like you know much more about all this than me ;-)

let me know if you need more information...
Comment 6 Till Korten 2009-12-06 00:58:55 UTC
p.s. I still think that neon 0.29 should be marked unstable (~x86) until this issue is fixed upstream either in subversion or in neon.

This seems like something of a version incompatibility between subversion and neon and two incompatible versions should not be in the stable tree right?
Comment 7 Rafał Mużyło 2009-12-07 02:51:15 UTC
The thing is that neon does work correctly,
in a way subversion does too.
It's only a matter of lack of foresight
- neon reports now more ssl errors than subversion was made to ignore.
Comment 8 Till Korten 2009-12-07 04:23:00 UTC
(In reply to comment #7)
> The thing is that neon does work correctly,
> in a way subversion does too.
> It's only a matter of lack of foresight
> - neon reports now more ssl errors than subversion was made to ignore.
> 

I think one way to see this is, that neon changed its ABI and subversion is incompatible with the new ABI when it comes to ignoring certificate errors.

In my case (and for every other client trying to connect to a server running a self signed certificate) this means that the subversion command line client is NOT functioning correctly (I cannot help the certificate errors and need subversion to be able to ignore them).

Therefore I still think that subversion 1.6.6 and neon 0.29 should not be in the same tree until subversion can interpret neon's error messages correctly (no matter what the underlying reasons for the problem are)!
Comment 9 Till Korten 2009-12-07 05:52:21 UTC
Apparently, the problem resolved itself after a emerge --sync and emerge -uDN world
The upgrade included perl, bash, python, cmake and others (38 packages total)

thanks for your efforts!
Comment 10 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2009-12-12 03:42:00 UTC
Anyway if the problem reappears, then somebody should report it e.g. to:
dev@subversion.apache.org