1

Versions

Subversion: version 1.6.11 (r934486)

Operating System: CentOS release 6.8 (Final)

Background

I have a variety of shell scripts that run as cronjobs on a CentOS machine. The shell scripts commit files to and checkout files from Subversion. Today all my scripts started failing with the following error

svn: OPTIONS of 'https://svn.int.mydomain.edu/eas': SSL handshake failed: SSL alert received: Error in protocol version (https://svn.int.mydomain.edu)

As a troubleshooting step I have ran the following command

openssl s_client -connect svn.int.mydomain.edu:443

And received the following output ( redacted slightly )

CONNECTED(00000003)
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.int.mydomain.edu
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.int.mydomain.edu
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5545 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: REDACTED
    Session-ID-ctx: 
    Master-Key: REDACTED
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1618275549
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
HTTP/1.1 408 Request Time-out
content-length: 110
cache-control: no-cache
content-type: text/html
connection: close

<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>
closed

As you can see I am getting a HTTP/1.1 408 Request Time-out at the end of the standard output. I can verify I have access to https://svn.int.mydomain.edu on this box, because a separate installation of svn works fine from that box ( an installation of SVN that came with a Jenkins plugin ).

Question

Does anyone have any thoughts on additional troubleshooting techniques here? I've tried to search for this issue but there is no fruitful responses.

1

The 408 response is simply because openssl didn't ever send an HTTP request. It did the TCP connection and the SSL handshake but that's it.

The important parts of the response are:

Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES256-GCM-SHA384
Verify return code: 0 (ok)

The 0 (ok) part means that as far as openssl is concerned, the SSL connection is fine. The certificate is valid and at least one cipher and protocol are supported.

But the error message from your bash script suggests that the SSL connection is not fine. My best guess for the reason is that the server has been upgraded and now no longer supports TLS 1.0 and TLS 1.1 and whatever your bash script is using for HTTPS requests doesn't support TLS 1.2. You can run a test for this by adding the -tls1 option to your openssl command.

If this results in something other than 0 (ok) then this TLS version incompatibility is most likely the problem.

It's also possible for the problem to be a mismatch of available ciphers. If you still get a 0 (ok) for TLS 1.0 then it might be worth looking in to the ciphers available at the server and the client.

It might also be worth looking at the last change made to the server or just trying to upgrade the client. (It's a shot in the dark but sometimes those work...)

1
  • 1
    This got me to the correct answer. I heard back from out Ops people and they told me "SSL is disabled, you need to use TLS", then I noticed the gnutls package was broken. I update that package and it works. So basically the upgrade to the client worked – Chris Maggiulli Apr 13 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.