Announcement

Collapse
No announcement yet.

SSL for subversion not working

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SSL for subversion not working

    Here's our setup - ubersvn/subversion are on a machine running RHEL 6.2, with two network interfaces (one for our LAN, and one for our WAN). I had this machine set up so that SVN is bound to the internal IP for port 80, and then used SSL on the standard 443 port (by enabling the ssl conf file in the httpd.conf file, and setting the certificate paths and the listen directive for the external IP in the httpd-ssl.conf file). This all worked perfectly. Should clarify that this is for the subversion portion - uberSVN admin is set to use SSL and use port 9900.

    Then, I had to change the (static) IP and the hostname of the box to put it into production. Internally, svn still works perfectly, but externally it fails. If I'm trying to access the repository in a browser, it just says not found, but in Tortoise it says:

    "Unable to connect to a repository at URL <URL snipped here - it's the correct one, and using https>. The OPTIONS request returned invalid XML in the response: XML parse error at line 1: no element found (<URL snipped again>)"

    I've checked the firewall config, and it's set to allow SSL on port 443 for the external interface (and again, this worked before the IP/hostname change). The certificate is a new one for the new hostname, and it works (I'm using it for uberSVN admin as well, and there are no problems there). I've also done a grep on the entire /opt and /etc directories for instances of the old hostname and came up empty.

    If I unbind the internal IP from 80, and open 80 in the external interface firewall config, this exact same URL (minus the "s" in https) works fine.

    The machine has been rebooted several times, and services restarted far more times. I've gone through all the log files and not seen anything that seems to be a clue, but if anyone can tell me something specific I should be looking for I'm happy to check again.

    Would very much appreciate any ideas. Thank you!

  • #2
    Oh - I should also point out that I've done a netstat on the server and the external URL shows that it's listening on port 443, with a process id that corresponds to subversion.

    When I try using the IP address instead of the FQDN of the server in the connection attempt, it warns me of a certificate mismatch (and correctly gives the server name as the server in the certificate), so it does seem to be properly reading the certificate. After I tell it to accept that, though, I get the same error as before.

    ETA: I may have found a clue after all. If I look in the ssl_error_log, it shows an error - file does not exist: /<ubersvn install dir>/htdocs/<name of repo I'm trying to reach>. My repo directory isn't in htdocs, so I don't know why it's looking for it there...

    Ah. I'm guessing that it knows where to look for them due to the 50-repositories.conf file. Now, when I look at that, it shows "VirtualHost *:80" at the top, so maybe that's only working when I'm going over regular HTTP, and not when I'm going over HTTPS? I'm still puzzled by the fact this was working fine before I changed the hostname and IP...this file didn't change at all.
    Last edited by teleute; 08-27-2012, 11:15 PM.

    Comment


    • #3
      Making very slow, irritating progress. I copied the directory sections from the 50-repositories file and also put them inside the VirtualHost _default_:443 section of the httpd-ssl.conf file. But for some reason, when I start Apache, it's saying that my auth server is unknown, and fails to start. (Mind you, this is the same auth server as in the 50-repositories file and it's fine there.) I commented out the auth sections and Apache started. Now, when I test from the external interface, it's properly redirecting to the repositories rather than the htdocs directory. But - it's saying that access is denied.

      At least, I think this is progress. Helped confirm that the problem was where I thought it was. I guess what really confuses me, given all this, is why it worked before?

      Does anyone have any ideas? This is going exceptionally slowly and this server was supposed to be online days ago...people here are about to start howling for blood. I would definitely appreciate if anyone's got any insight...

      Thanks!
      Last edited by teleute; 08-28-2012, 05:59 PM.

      Comment


      • #4
        It's working!!! Whew! (Still have to get RADIUS plugged in now, but...*sigh*)

        Honestly, it does feel kind of hack-y, though. So as I mentioned before, I had to copy the info from the 50-repositories.conf file into the httpd-ssl.conf file in the :443 virtual host. The issue then was that it was saying my auth server was unknown. However, looking more closely I noticed that the code I copied had my server name as the authprovider, whereas usually that's LDAP or whatever. And there was not LDAP address. Looking further, I found that there are aliases set for these in 35-ldap.conf. Which was being loaded *after* httpd-ssl, and so the aliases weren't defined yet! I moved httpd-ssl after the reading of the conf.d directory, and now it's fine! Whew!

        So the three things I'm wondering are:

        1. Are any of these changes things that could be accidentally overwritten by updates, or changes in the interface? (Other than obviously changing the .conf files themselves through the interface)?

        2. Is this actually the way it should be done? Because if we add a repository, then we have to remember to manually go and add it into the httpd-ssl.conf file.

        3. Why on earth did it work before the IP change, without this stuff done, if this is what it requires?

        Thanks!

        Comment


        • #5
          Finally got the RADIUS authentication working - figured I'd put some info here in case anyone else is trying to do this in future.

          As far as I can tell, there are three RADIUS modules for Apache. There's the one that is actually part of Apache (I can't recall the exact name), but it doesn't appear to support one time passwords. This left mod_auth_radius (from FreeRadius), and mod_auth_xradius. The former uses cookie-based authentication caching, which I could not get to work at *all* consistently with SVN (or with Mantis, which is the other app we're running this with). THis is because they both generally make multiple requests in very short order, and the cookie handling doesn't usually work fast enough to make it work. They even acknowledge that on the FreeRadius page, and suggest a workaround of basically an authentication portal page, which isn't really workable for SVN. The latter was really the only option, then.

          The trick with mod_auth_xradius is that it's quite old, and I couldn't find any active lists or forums to get any guidance. I implemented it as per the instructions, and this worked on our Mantis install of Apache, but not the UberSVN one. Again, the issue was with the authentication caching. I was using the easier of the two methods, a dbm file-based cache. However, something about the UberSVN compilation of Apache (I'm guessing the default dbm libraries, as those are set at compile-time) was meaning that the dbm file was getting written in a different format than the xradius module could understand. (This appears to be quite consistent with what I've read, which is that there are two main branches of dbm libraries, that create different file types, and they're not compatible unless you've got some kind of emulation mode in place.)

          Therefore, I had to go with the other form of caching, and create a memcached server and import the special apr_memcache libraries from the people that made the radius module, recompile, etc... This seemed to work for RADIUS auth and caching, but I was then getting denied at the SVN level. At this point I had to disable the UberSVN user management and switch to alternative_authz files, since the user names were coming in from RADIUS as "domain\user", which didn't match with the users UberSVN recognized.

          This seems to finally have gotten things sorted. Whee! I really hope this is potentially useful to someone else someday, with as much effort as I put into it.

          Comment


          • #6
            Originally posted by teleute View Post
            It's working!!! Whew! (Still have to get RADIUS plugged in now, but...*sigh*)

            Honestly, it does feel kind of hack-y, though. So as I mentioned before, I had to copy the info from the 50-repositories.conf file into the httpd-ssl.conf file in the :443 virtual host. The issue then was that it was saying my auth server was unknown. However, looking more closely I noticed that the code I copied had my server name as the authprovider, whereas usually that's LDAP or whatever. And there was not LDAP address. Looking further, I found that there are aliases set for these in 35-ldap.conf. Which was being loaded *after* httpd-ssl, and so the aliases weren't defined yet! I moved httpd-ssl after the reading of the conf.d directory, and now it's fine! Whew!

            So the three things I'm wondering are:

            1. Are any of these changes things that could be accidentally overwritten by updates, or changes in the interface? (Other than obviously changing the .conf files themselves through the interface)?

            2. Is this actually the way it should be done? Because if we add a repository, then we have to remember to manually go and add it into the httpd-ssl.conf file.

            3. Why on earth did it work before the IP change, without this stuff done, if this is what it requires?

            Thanks!
            In your very first post you say this (emphasis mine):

            Originally posted by teleute View Post
            Here's our setup - ubersvn/subversion are on a machine running RHEL 6.2, with two network interfaces (one for our LAN, and one for our WAN). I had this machine set up so that SVN is bound to the internal IP for port 80, and then used SSL on the standard 443 port (by enabling the ssl conf file in the httpd.conf file, and setting the certificate paths and the listen directive for the external IP in the httpd-ssl.conf file). This all worked perfectly.
            So my guess is that you didn't enable SSL through the UI, which is the way we expect you to do it.

            That's probably why it worked initially (you massaged the Apache config behind uberSVN's back) and then broke when you changed the IP (uberSVN still thinks Apache is on port 80, which is why you get the wrong port in the 50-repositories.conf file and have to manually copy config about when you add repositories.)

            If you enable SSL through the UI as shown in the screenshot below, then uberSVN should write out the correct Apache config when you add repositories. You should not have had to do anything to your httpd.conf file or do any copying from 50-repositories.conf.



            Hope this helps.

            Comment


            • #7
              Originally posted by mbooth View Post
              So my guess is that you didn't enable SSL through the UI, which is the way we expect you to do it.

              That's probably why it worked initially (you massaged the Apache config behind uberSVN's back) and then broke when you changed the IP (uberSVN still thinks Apache is on port 80, which is why you get the wrong port in the 50-repositories.conf file and have to manually copy config about when you add repositories.)

              If you enable SSL through the UI as shown in the screenshot below, then uberSVN should write out the correct Apache config when you add repositories. You should not have had to do anything to your httpd.conf file or do any copying from 50-repositories.conf.

              Hope this helps.
              However, I also say in my first post that "SVN is bound to the internal IP for port 80", which we need. On our LAN interface, it has to be accessed via port 80, and on our WAN interface via port 443. So enabling it through the UI doesn't work in this situation.

              Comment


              • #8
                Originally posted by teleute View Post
                However, I also say in my first post that "SVN is bound to the internal IP for port 80", which we need. On our LAN interface, it has to be accessed via port 80, and on our WAN interface via port 443. So enabling it through the UI doesn't work in this situation.
                I see, it was not obvious to me from that post that you wanted it to listen on both ports. I'm afraid that's a configuration that is not really supported at the moment.
                Last edited by mbooth; 09-04-2012, 03:30 PM.

                Comment


                • #9
                  Originally posted by mbooth View Post
                  I see, it was not obvious to me from that post that you wanted it to listen on both ports. I'm afraid that's a configuration that is not really supported at the moment.
                  Fair enough - so I think that definitively answers #2. #3 may remain a mystery, then, although it's *really* puzzling me. Any thoughts on #1? Will any updates wipe out any of this configuration, do you think? Do they generally touch these config files?

                  Thanks!

                  Comment


                  • #10
                    Originally posted by teleute View Post
                    Fair enough - so I think that definitively answers #2. #3 may remain a mystery, then, although it's *really* puzzling me. Any thoughts on #1? Will any updates wipe out any of this configuration, do you think? Do they generally touch these config files?

                    Thanks!
                    Regarding #1, maybe. The numbered files in conf/conf.d such as 50-repositories.conf are kinda no-go areas for humans as changes in the UI will cause those files to be re-written in some cases. The httpd-ssl.conf file you have used is safe (albeit un-supported) because it's not normally used by uberSVN at all -- the relevant SSL config would be added to one of the numbered files should you configure it through the UI.

                    Installing updates never overwrites config files intended for human editing. Instead config files will be installed with a file name like httpd.conf.new-<timestamp> or if they are not intended for human editing, the new version will be installed and a back up of the old one will be named like httpd.conf.save-<timestamp>

                    Without knowing exactly how you configured it originally, I can't comment on #3 -- maybe the individual repositories were not configured to use LDAP authn in the original setup, which would cause the load order not to matter.
                    Last edited by mbooth; 09-04-2012, 04:19 PM.

                    Comment


                    • #11
                      Originally posted by mbooth View Post
                      Regarding #1, maybe. The numbered files in conf/conf.d such as 50-repositories.conf are kinda no-go areas for humans as changes in the UI will cause those files to be re-written in some cases. The httpd-ssl.conf file you have used is safe (albeit un-supported) because it's not normally used by uberSVN at all -- the relevant SSL config would be added to one of the numbered files should you configure it through the UI.

                      Installing updates never overwrites config files intended for human editing. Instead config files will be installed with a file name like httpd.conf.new-<timestamp> or if they are not intended for human editing, the new version will be installed and a back up of the old one will be named like httpd.conf.save-<timestamp>

                      Without knowing exactly how you configured it originally, I can't comment on #3 -- maybe the individual repositories were not configured to use LDAP authn in the original setup, which would cause the load order not to matter.
                      I didn't actually end up making any changes to the 50-repositories file (I'd tried it originally, but it didn't work) - I just copied the info from there into the httpd-ssl.conf file. So the only two files I've changed are httpd.conf and httpd-ssl.conf. Sounds like I'll be okay, then. Thanks!

                      Comment

                      Working...
                      X