julianfoad_at_apache.org wrote on Thu, Aug 02, 2018 at 14:44:02 -0000:
> +++ subversion/site/publish/docs/release-notes/1.10.html Thu Aug 2 14:44:02 2018
> @@ -353,6 +353,43 @@ In particular, the behaviour of builds <
>
> </div> <!-- svnserve-use-sasl -->
>
> +<div class="h4" id="new-ca-keys">
> +<h4>New CA keys may be required
> + <a class="sectionlink" href="#new-ca-keys"
> + title="Link to this section">¶</a>
> +</h4>
> +
> +<p>
> +Some binary distributions of this new Subversion version
> +may link to a newer OpenSSL version than previous distributions.
> +This may lead to different behavior.
Should we state that it's possible, though less likely, for a new Subversion
1.9 binary package to be built against OpenSSL 1.1? I suppose we should do so
if OpenSSL 1.1 is API-compatible with 1.0 [so a libssl1.0 consumer can
recompile against libssl1.1 with no other changes].
This does mean that users of such new 1.9 binaries will need to read the 1.10
release notes to find this info, but I don't immediately see a better option.
> +<p>
> +Especially, some distributions may link this Subversion release to OpenSSL 1.1 instead of OpenSSL 1.0.
> +OpenSSL 1.1 does not allow md5 hashes for CA keys anymore.
As I said, I doubt that's the only incompatible change between 1.0 and 1.1, so
we should be linking to information about further incompatibilities.
As a datapoint, Debian's libssl1.1 package (which I looked into when drafting
replies earlier in the thread) has an on-upgrade notice that warns that TLS 1.0
support is being dropped, but has no upgrade notice about md5. I conclude that
the Debian package maintainer judges the TLS change to be more impactful than
the md5 change.
(To see the notice at 'apt upgrade' time one needs to install apt-listchanges.)
> +When using client certificates signed by such a CA,
> +the new Subversion client may fail with <tt>An error occurred during SSL communication</tt>.
> +You can analyze the underlying cause by first converting the client certificate from p12 to pem by
> +<pre>
> +openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem
> +</pre>
> +and then testing the SSL connection by
> +<pre>
> +openssl s_client -connect example.com:443 -servername example.com -cert cert.pem
> +</pre>
Is it possible to use «s_client -certform $FOO -cert cert.p12» here and skip
the conversion step? It's not clear to me from the manpage on my system (and I
can't easily test this).
State somewhere to look into the server-side error logs in case they contain
more information?
> +If this test connection fails with <tt>ca md too weak</tt>
> +then creating new CA keys using sha256 instead of md5
> +and corresponding new client certificates should solve the problem.
This bit of information (a) is duplicated between our releases notes and our
FAQ, (b) should live in OpenSSL's docs rather than ours. [I have made point (b)
in another thread so let's concentrate in this thread on point (a).]
> +</p>
> +
> +<p>
> +See also <a href="/faq.html#ssl-communication-error">When performing Subversion operations
> +over SSL, I get the error <tt>An error occurred during SSL communication</tt></a>
> +</p>
> +
> +</div> <!-- new-ca-keys -->
> +
> </div> <!-- compat-misc -->
>
> </div> <!-- compatibility -->
> +++ subversion/site/publish/faq.html Thu Aug 2 14:44:02 2018
> @@ -4158,6 +4160,48 @@ Subversion perform a normal recursive co
>
> </div>
>
> +<div class="h3" id="ssl-communication-error">
> +
> +<h3>When performing Subversion operations
> + over SSL, I get the error <tt>An error occurred during SSL communication</tt>
> + <a class="sectionlink" href="#ssl-communication-error"
> + title="Link to this section">¶</a>
> +</h3>
> +<p>
> +SSL communication errors can have various reasons.
> +You can use the openssl binary to debug the ssl connection.
> +<pre>
> +openssl s_client -connect example.com:443 -servername example.com
> +</pre>
> +If you use a client certificate,
> +then you need to convert Subversion's client certificate from pkcs12 to pem first:
> +<pre>
> +openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem
> +</pre>
> +Then you can use:
> +<pre>
> +openssl s_client -connect example.com:443 -servername example.com -cert cert.pem
> +</pre>
The -certform question above applies here too, as does the suggestion to
recommend to look into the server-side error log.
> +If you are using ssl-authority-files in <tt>.subversion/servers</tt> to verify
> +the server cert you can get <tt>s_client</tt> to do the same with the additional
> +parameter:
> +<pre>
> +openssl s_client ... -CAfile path/to/authority.pem
> +</pre>
> +The <tt>s_client</tt> output may indicate what problem is occurring.
> +</p>
> +
> +<p>
> +For example, if <tt>s_client</tt> reports
> +<pre>
> +error setting certificate
> +140258270184704:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak:../ssl/ssl_rsa.c:303:
> +</pre>
> +then creating new CA keys with sha256 instead of md5 should solve the problem.
> +</p>
> +
> +</div>
> +
> </div>
>
> <div class="h2" id="developer-questions">
>
>
Received on 2018-08-03 13:04:33 CEST