SSL handshake failed: SSL alert received

[Brandon L. Wisenburg]

Greetings List,
I am getting an error when attempting to svn update.

svn update
svn: OPTIONS of 'https://domain/src': SSL handshake failed: SSL alert received: Handshake failed (https://www.domain.com)

Odd part is I am not sure why it is failing. Has anyone seen this issue before?

===========================

[Johan Corveleyn]

On Wed, Jul 11, 2018 at 5:32 PM, Brandon L. Wisenburg

Post by Brandon L. Wisenburg
Greetings List,
I am getting an error when attempting to svn update.
svn update
svn: OPTIONS of 'https://domain/src': SSL handshake failed: SSL alert
received: Handshake failed (https://www.domain.com)
Odd part is I am not sure why it is failing. Has anyone seen this issue before?

I suppose you hand-edited the error message to replace the actual
domain name with 'domain'. To double-check: the first url in the error
message is without the www.*.com, yes? So the actual repository url
does not have www.*.com, but the svn client seems to be forced to
perform its ssl handshake with www.domain.com. Perhaps a proxy that is
interfering?

Other than that: a quick thing to try is to access the repository url
from a web browser, and see if there is any connection problem or
anything strange with the ssl certificate / connection.

[Johan Corveleyn]

[ If possible, this list prefers bottom-posting / inline replies in
plain text. More below ... ]

On Wed, Jul 11, 2018 at 10:07 PM, Brandon L. Wisenburg

Hi Johan,
Yes, I edited out the actual domain. I can hit the URL via a browser and get prompted for a password. The SSL Cert also checks out OK via SSLChecker. Any other thoughts?

Hm, just a generic problem-solving thought: this worked before (since
you created a checkout from that url), so ... what changed? Something
must have changed to cause the error.

Is your pc the only one getting this error, and it works fine on
other's pc in your environment? That would help pinpointing the
problem to a either a central component or just your pc.

First suspects, IMHO, are:
- Something in the network infrastructure, or with the network
configuration of your pc. Perhaps your connection is now sent to /
manipulated by a proxy, whereas it wasn't before. Maybe you can
experiment a bit with the http-proxy-* options (for instance configure
http-proxy-exceptions for your domain) in the 'servers' configuration
file in your Subversion runtime configuration directory
(~/.subversion/servers on unix, or %APPDATA%/Subversion/servers on
Windows).
- A change in the server-side configuration (the httpd configuration).

[Philip Martin]

Post by Brandon L. Wisenburg
svn update
svn: OPTIONS of 'https://domain/src': SSL handshake failed: SSL alert
received: Handshake failed (https://www.domain.com)

You don't say which version of Subversion you are using but that looks
like an old client as a newer client would include an error number in
the error message. An old client probably uses an old SSL library and
it is possible that the client's SSL library doesn't support the SSL
connection that the server is trying to establish.

If the client has the OpenSSL tools installed you can use

openssl s_client -connect domain:443

to see lots of detail about the SSL negotiation.

[Philip Martin]

Post by Philip Martin

Post by Brandon L. Wisenburg
svn update
svn: OPTIONS of 'https://domain/src': SSL handshake failed: SSL alert
received: Handshake failed (https://www.domain.com)

You don't say which version of Subversion you are using but that looks
like an old client as a newer client would include an error number in
the error message. An old client probably uses an old SSL library and
it is possible that the client's SSL library doesn't support the SSL
connection that the server is trying to establish.
If the client has the OpenSSL tools installed you can use
openssl s_client -connect domain:443
to see lots of detail about the SSL negotiation.

That may not be the problem. The client appears to have sent an OPTIONS
request which happens after the SSL connection has been established.

If the client has the socat proxy installed you can use the instructions
here:

https://subversion.apache.org/docs/community-guide/debugging.html#net-trace-socat

to get a network trace of the OPTIONS request and response.

[Brandon L. Wisenburg]

Hi Philip
Thanks for the reply. The odd part is when I do the openssl s_client it looks like the handshake is successful.

----- Original Message -----
From: "Philip Martin" <***@codematters.co.uk>
To: "Philip Martin" <***@codematters.co.uk>
Cc: "brandon" <***@wisenburg.com>, "users" <***@subversion.apache.org>
Sent: Thursday, July 12, 2018 4:38:46 AM
Subject: Re: SSL handshake failed: SSL alert received

Post by Philip Martin

Post by Brandon L. Wisenburg
svn update
svn: OPTIONS of 'https://domain/src': SSL handshake failed: SSL alert
received: Handshake failed (https://www.domain.com)

You don't say which version of Subversion you are using but that looks
like an old client as a newer client would include an error number in
the error message. An old client probably uses an old SSL library and
it is possible that the client's SSL library doesn't support the SSL
connection that the server is trying to establish.
If the client has the OpenSSL tools installed you can use
openssl s_client -connect domain:443
to see lots of detail about the SSL negotiation.

That may not be the problem. The client appears to have sent an OPTIONS
request which happens after the SSL connection has been established.

If the client has the socat proxy installed you can use the instructions
here:

https://subversion.apache.org/docs/community-guide/debugging.html#net-trace-socat

to get a network trace of the OPTIONS request and response.

[Philip Martin]

Post by Brandon L. Wisenburg
Hi Philip
Thanks for the reply. The odd part is when I do the openssl s_client
it looks like the handshake is successful.

Yes, that's to be expected because the client is sending OPTIONS. You
haven't told us which version of Subversion/SSL you are using but I
still suspect the client SSL library is too old. It's not some obvious
incompatibility, such as incompatible encryption algorithm, but
something more obscure, e.g. missing client support for SNI.