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.
- Hostname: *.example.net
- Valid: from Mon, 11 Jun 2007 00:00:00 GMT until Wed, 15 Sep 2010 23:59:59
- 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:
maybe neon should be marked ~x86 until this issue is fixed?
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)
option to save certificates permanently is missing
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.
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
> 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:
Serial Number (hex): 00c5f5b68a49ce7ae5
Not Before: Sat Nov 07 11:44:09 UTC 2009
Not After: Sun Nov 07 11:44:09 UTC 2010
Subject Public Key Algorithm: RSA
Exponent (bits 24):
Subject Key Identifier (not critical):
Authority Key Identifier (not critical):
Basic Constraints (not critical):
Certificate Authority (CA): TRUE
Signature Algorithm: RSA-SHA
The second check returns:
verify error:num=18:self signed certificate
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: