Multiple HTTPS / SSL Sites For One IP http://howtoforge.com/enable-multiple-https-sites-on-one-ip-using-tls-extensions-on-debian-etch Would just like to comment that I have completed a full install and test of the new TLS implementation and it works a treat. Not in production yet but will be soon. Some very minor issues with typo's on the howto page, maybe till or falko could correct them cd /usrsrc/apache2 should be cd /usr/src/apache2 and just to make sure people understand that there are 2 entries for the Check ob bereits ein SSL Cert auf der IP Existiert in the /home/admispconfig/ispconfig/lib/classes/ispconfig_isp_web.lib.php file. I also experienced a minor issue where the - kept changing to a . but this may have been just my machine and the use of puty. The only other thing people need to know is that this takes a long time to complet and preferably needs a fast internet connection or it could take more than 6 or 8 hours to complet on slower connections so have a coffee and engoy. Also just wondering is Afer upgrading ispconfig if the /home/admispconfig/ispconfig/lib/classes/ispconfig_isp_web.lib.php file will need editing every time. Thanks for a howto that makes life a lot better and has been asked for many many times. Till and falko will enjoy not having to say Thats not possible Thanks Steve
compatibility of tls and suphp I am now wondering if TLS Multi site ssl is compatible with suphp Has anyone tried this yet. If its not compatible what would be the alternative. suexec, apache2-mpm-itk. both of which are not talked about much on these forums. anyway thought Id ask and see is there is anyone with any experience, but honestly I don't expect any takers. Thanks Steve
I seem to remember I tested it with suphp a while back without problem, but I was doing a lot of testing and switching with suPHP and SuExec at the time, so I can't be certain. I don't think it should be an issue, does suPHP really care what the underlying transport is? I would have thought that browser support for SNI would be a far bigger issue. If 80% or whatever of people connecting use browsers able to support SNI, is it wise to implement it?
Probably depends on the site. There are realy only 2 browsers to worry about and thats IE and Firefox nothing else realy matters (Sorry to those that use Apple's) and most websites would show these two as being closer to 90% or higher of all there users so its probably not going to have much affect negatively as both IE and Firefox support SNI. The other thing to consider is that within the next 6 to 12 months most if not all browsers will develop support for the new protocols. A simmple comment on the website explaining that the site requires IE or Firefox or Opera to work correctly untill support is more universal seems simple enough to do. I dont know about search engins and there ability to follow NSI URL's but Google and Yahoo are probably both good to go, there the two biggies. Probably best to check log files and determin on a site by site basis if its going to have an impact or not. Thanks for the suphp update Ill give it a go ASAP. Steve
Can you tell me what point in the how-to you got to? Also, what do you have in the /var/log/apache2/error.log? Some times when you don't have the required packages or the wrong ones it can give these results. I just found out that there are newer apache2 packages with a higher version then the ones built in the how-to. A newer package version can cause conflicts with an older package version. This does not mean the one you built is older, it just means the version is older. I'm going to do a little more research and get back to you on this one.
apache source I did a new install last week and the apache source numbers were different so I changed them in the process where needed and it all worked OK
I just like to comment that its a very long winded process and It would be better if it would be done right up front in the initial server setup process instead of after. Also Im not to sure about the update process and what affect that will have on the system. ie is it going to be OK to do a normal apt-get update in the future and what happens when there is a dist update not to mention updating ispconfig and that everytime we will have go in and manualy adjust several files. It all seems to add to the complexity of running and maintaining the system.
I agree. I wonder if there is a way to compile just the packages you need, not all the packages within the Apache2 source. For instance, when I recompile Apache2 I also add quota to WEBDAV, I don't need everything else. Also, there is a way you can use apt to use your new packages as a repository. I think I'll add that to the how-to to make the process less error prone. Then all you would have to do is run 'apt-get upgrade' and it would install all the packages necessary without you having to guess which ones to install.
http://www.outoforder.cc/projects/apache/mod_gnutls/ some updates as to using this howto Yes it does what it claims BUT. After some further testing I found that becouse it is so extensively modified that there is limmited or no room for further changes to the system. I was unable to install and use suphp for one example, so in the end I have been unable to use this great possibility. On the other hand I have come accross what looks like a better alternative, mod_gnutls http://www.outoforder.cc/projects/apache/mod_gnutls/ There isnt much info about how to configure it as yet but looks like a better alternative as the install is just like any other module I am wondering if anyone has used this module and what was there procedure to get it working. Thanks Steve
This might be a very stupid question, but how is the compilation of the patched apache at all possible with an etch building pbuilder? After looking at the patch a bit and trying this and that I got the impression that it needs a version of libssl-dev that knows what tls-extensions are, which isn't the case for the libssl in etch that pbuilder is instructed to use. What makes me think so are those lines of the patch: Code: +#ifndef OPENSSL_NO_TLSEXT +#ifndef SSL_CTRL_SET_TLSEXT_HOSTNAME +#define OPENSSL_NO_TLSEXT +#endif +#endif I commented them out, hoping that thinks will start working that way, but it just gave me a lot of function not declared errors and similar, strenghtening my belief that I'm compiling against the wrong libssl. Any ideas? PS: gnutls does look interesting, but since mod_ssl will support sni per default soon (or at least I think I read something like that recently) the trouble of hacking ispconfig to work with it doesn't seem that necessary (to me at least). The problem with gnutls is that it uses its own options for the apache config and getting ispconfig to use them too would require more that just commenting out lines.
Apache works, but doesn't support SNI The patch attached to the article made some fuzz, so I've tried this: https://issues.apache.org/bugzilla/attachment.cgi?id=19676 I've followed the instructions, but the compiled mod_ssl doesn't work Output of the pbuilder apache2 compilation shows that ... Selecting previously deselected package libssl-dev. Unpacking libssl-dev (from .../libssl-dev_0.9.8c-4etch1_i386.deb) ... ... so, libssl-dev's etch version used along the compilation. In the article the ssl compilation is after the apache, but apache depends on ssl... I don't understand it Etch's libssl doesn't contain the required TLS extension, I think, and can that way produce correct mod_ssl binary??? However, how can I test the result? Is there any method by for example 'openssl s_client ...'? Is there any way to put the newly compiled libssl-dev into the pbuilder's environment?
I believe you have a point here. Since the most recent major update to openssl it seems this how-to doesn't work any more. I believe this can be fixed by reconfiguring pbuilder to re-use packages built by pbuilder. I had left this bit out of configuring pbuilder because I felt it was unnecessary. now it appears so. Follow the link below to reconfigure pbuilder, build OpenSSL first, and then Apache2. I will rewrite this how-to when I get the chance. In the mean time, can you let me know if configuring pbuilder and compiling in this order fixes the issue? http://edseek.com/%7Ejasonb/articles/pbuilder_backports/pbuilderbuild.html#pbuilderhook -Archer
It works now Thank you for the answer! OK, yesterday I continued thinking on the problem and resolved that by one simplier method, but it not so nice as yours. That was the trick: # pbuilder update --distribution lenny --override-config Lenny contains TLS extensions capable libssl-dev now, and after apache2's compilation/installation only one extra package (libsqlite-0, or something like this) tainted my pure Etch installation (almost pure, because I installed php xcache, and it needed lenny packages too - http://www.howtoforge.com/xcache-php5-apache2-debian-etch) By the way your how-to is excellent one, thank you for the original idea!!
Rebuilding Openssl is unnecessary if you are going to be installing from Lenny. TLS extensions are enabled by default. You can see it here in the changelog. http://packages.debian.org/changelogs/pool/main/o/openssl/openssl_0.9.8g-10.1/changelog Also, many have suggested using mod_gnutls. I believe mod_gnutils is faster, cleaner, and a better way of going about this. But there were too many dependencies to backport GnuTLS for mod_gnutls on etch. mod_gnutls works great, but requires you to upgrade to Lenny. I tested mod_gnutls with ISP3, and it works like a charm. Of course there were a lot of things that were a little unclear about configuring Apache2, but in the long run it is still in the testing stage, not stable. Hmm.. mod_gnutls would make another good how-to.
