The old virtual site’s apache config file had the site bound to *:443, so when I added the new site I changed the old one to [Old IP Address]:443, so it wouldn’t conflict with the new one which was bound to [New IP Address]:443. While logically it seemed like that should have worked, it didn’t, and was serving up the old cert for the new site.

I fixed the issue by changing the binding for the old virtual site back to *:443, while leaving the new one on [new IP address]:443. To me, it seems like this shouldn’t work, and that the *:443 would catch all the requests, but apparently that’s how it is supposed to be, and the binding with the IP address overrides the wildcard binding. Who knew?

One way to fix Apache serving up the wrong SSL certificate is a post from: WebSight Design, Inc. company blog. With headquarters in the San Francisco bay area, WebSight Design, Inc. has been providing world class web engineering, creative design and hosting solutions since 1995. WebSight Design

So, I am assuming that you are trying to access a Subversion repository via an https url and you are getting the message “ssl not supported” or something similar to this. I know, it sucks and it’s pretty frustrating. I promise you however, if you do *exactly* what I spell out below, in the sequence I list… you will be up and working in about 15-20mins. The only other assumption here is that you are using Ubuntu or some other Debian-based Linux distro that supports the APT package manager.

It’s important to know that Subversion uses a module called Neon to provide ssl connectivity. The key here is to use the version of Neon for your specific release of Subversion. This is key to everything else that follows. Don’t just grab the latest versions of Subversion and Neon and assume they will work correctly together. So with that… let’s get to work.

First, make sure the following packages are installed on your server:
GCC

Expat

Libxml-dev

Next, download latest Subversion files:

NOTE: “X” above is a placeholder for your version no.

Untar em’ in this order:

Once you have extracted the files, open the file ”

“. Locate the section on Neon. It will state which version you need to download and compile with this version of Subversion.

Make sure you are *not* in the Subversion directory you just created. Then go ahead and download Neon:

NOTE: The “X” above is placeholder for the version of Neon you need.

Next, extract the archive:

Now is where the fun begins. You need to compile and install Neon. Do the following from *within* the Neon directory you created:

It’s important to note that Neon gets installed to /usr/local by default. You need to note that as you will now need it when compiling and installing Subversion.

Change back to the Subversion folder:

Compile and install Subversion:

Now, realize that the Subversion compilation and installation process takes a long time to complete. So just be patient. You can ignore any warning messages that scroll by. You only need to be concerned with error messages or if the installation stops for any reason.

Once compilation and installation are complete you need to confirm that you are running the version of Subversion you just tried to install:

If you get *anything* other than the version number you thought you installed, something went horribly wrong. Go back to the very beginning of this and try again. Most time folks get errors it is because that don’t have the prerequisite tools and utilities installed. If you see the version you wanted… you’re all good!

Compile / Configure Subversion w/SSL Enabled is a post from: WebSight Design, Inc. company blog. With headquarters in the San Francisco bay area, WebSight Design, Inc. has been providing world class web engineering, creative design and hosting solutions since 1995. WebSight Design