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
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