Summary: | subversion won't save bad certificates permanently with neon 0.29 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Till Korten <webmaster> |
Component: | [OLD] Development | Assignee: | 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
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 ...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. Please report this problem to Neon upstream. http://lists.manyfish.co.uk/mailman/listinfo/neon 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. (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... 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? 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. (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)! 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! Anyway if the problem reappears, then somebody should report it e.g. to: dev@subversion.apache.org |