# Downgrade OpenSSL back to 0.9.8

## oracleguy

I am having a trouble with my Gentoo server (64-bit) with SVN that I think is related to updating OpenSSL to 1.0. Older versions of subversion clients can't seem to connect to it over HTTPS with SSL handshake errors. I wanted to try and see if rolling back the OpenSSL version fixed the issue but it seems the ebuild for 0.9.8 doesn't install the header files anymore. When I unemerged 1.0 and installed 0.9.8 and then tried to compile anything against it, it couldn't find the header files for OpenSSL.

Any ideas how I can do that?

As an aside the SVN issues I am having are these with TortoiseSVN on Windows:

```
OPTIONS of 'https://server/svn/repos/repo1/trunk': SSL handshake failed: SSL error code -1/1/336032856 (https://server)
```

And with SVN 1.6.12 command line binaries on Ubuntu with OpenSSL 0.9.8, it has this error: 

```
svn: OPTIONS of 'https://server/svn/repos/repo1/trunk': SSL handshake failed: SSL error: A TLS warning alert has been received. (https://server)
```

The server is running SVN 1.6.13 with Apache 2.2.16 and neon 0.29.3 (if neon matters).

Any ideas on that?

----------

## Hu

Can a client using openssl 1.0 communicate with the server using openssl 1.0 or are all clients broken?

----------

## oracleguy

On my Gentoo laptop which I have upgraded to OpenSSL 1.0.0, SVN works fine and can communicate to the server without any issue.

----------

## SamuliSuominen

Just upgrade to 1.0.0a-r3 and run the suggested commands (printed by the end of openssl-1.0.0a-r3 emerge, the postinst message):

revdep-rebuild --library libssl.so.0.9.8

revdep-rebuild --library libcrypto.so.0.9.8

And no, plain revdep-rebuild *won*t work, as those files are preserved and it won't find anything broken...

SVN works fine here

----------

## oracleguy

 *ssuominen wrote:*   

> Just upgrade to 1.0.0a-r3 and run the suggested commands (printed by the end of openssl-1.0.0a-r3 emerge, the postinst message):
> 
> revdep-rebuild --library libssl.so.0.9.8
> 
> revdep-rebuild --library libcrypto.so.0.9.8
> ...

 

I already did that and my SVN seems to work fine from the one client that has been upgraded to 1.0.0a-r3. And I can browse the repositories fine over HTTPS in Firefox on multiple computers (Windows and Linux). It just doesn't seem to work with SVN clients using 0.9.8 still.

----------

## Etal

 *oracleguy wrote:*   

> And I can browse the repositories fine over HTTPS in Firefox

 

Firefox acutally uses its own SSL implementation (nss).

----------

## oracleguy

 *Etal wrote:*   

>  *oracleguy wrote:*   And I can browse the repositories fine over HTTPS in Firefox 
> 
> Firefox acutally uses its own SSL implementation (nss).

 

That is good to know.

I should have also clarified, the one client that does work, is using Subversion 1.6.12 (and has OpenSSL 1.0) and I used the SVN command line binaries to update from the SVN repository (over HTTPS) and it worked fine.

I just wanted to be able to downgrade OpenSSL on my server to help try and isolate the source of the problem.

----------

## toralf

I've subversion 1.6.13 installed at a x86 32bit system, the upgrade to openssl-1.x was more or less flawlessly and a "svn update" works flawlessly for the wireshark repository:

https://anonsvn.wireshark.org/wireshark/trunk

----------

## oracleguy

So I figured out what the problem was; it appears (now) the ServerName directive for the site in Apache and the DNS name being used to access the site must match the common name in the SSL certificate. Once I did that both of the error messages in my original post went away.

----------

## Hu

As a guess based on the apparent resolution described by oracleguy, the new OpenSSL may have enabled Apache to receive and use SNI, at which point Apache became unhappy that the SNI it received from the client was inconsistent with the name that Apache was told to use.

----------

## Cygon

Thanks for posting your solution, oracleguy!

I was having the very same issue after upgrading to openssl 1.0 - some clients could access the repository, some couldn't. Correcting the ServerName for the vhost that was responsible for Subversion solved the issue across the board.

----------

## jlpoole

 *oracleguy wrote:*   

> So I figured out what the problem was; it appears (now) the ServerName directive for the site in Apache and the DNS name being used to access the site must match the common name in the SSL certificate. Once I did that both of the error messages in my original post went away.

 

I recently upgraded and had the same error message when trying to access my server from Windows using Tortoise SVN.  I found my my 00_default_ssl_vhost.conf had the servername set to "localhost", so altered the line

```
Servername [my server's name]
```

and then rebooted apache and successfully checked-out a tree from Subversion.

Thanks oracleguy.

----------

## sidamos

Thanks a lot for this tip! I was searching for 2 weeks why my OpenSSL 0.9.8 clients could not connect to my server anymore after upgrading the server to OpenSSL 1.0.0.

----------

