Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The current SSL code happily generates multiple SSL vhosts without checking if there's already one on the same IP/port combination. This yields the following warning:
[Fri Feb 12 15:44:46 2010] [warn] Init: SSL server IP/port conflict: aegir.koumbit.net:443 (/var/aegir/config/vhost.d/aegir.koumbit.net_443:1) vs. id.koumbit.net:443 (/var/aegir/config/vhost.d/id.koumbit.net_443:1)
[Fri Feb 12 15:44:46 2010] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
I have had erratic results with this configuration. Sometimes id.koumbit.net would end up pointing to the aegir platform, for example.
There's a proper solution for this, i need to dig into my various bookmarks... This may also be as simple as implementing #537016: simple certificate management.
Comment | File | Size | Author |
---|---|---|---|
#5 | provision_ssl_drush_inc.txt | 893 bytes | timwood |
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedComment #2
anarcat CreditAttribution: anarcat commentedThis is one of the things I had in mind but it doesn't (ugh) support Windows XP clients:
http://en.wikipedia.org/wiki/Server_Name_Indication
This is now part of Apache2 in debian squeeze:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461917
Comment #3
timwoodanarcat,
If you utilize a wildcard certificate you can do SSL virtualhosting without SNI, provided all the hostnames fall under the wildcard. This is most likely the setup anyway because of DNS wildcard usage with Aegir.
Comment #4
anarcat CreditAttribution: anarcat commentedI am aware of that. What I am saying here is that apache yields a warning and sometimes has unexpected behavior when doing that.
Comment #5
timwoodMy problem is when using the SSL features Aegir provisions a site on my SSL port (443) without the Apache SSLCertificateFile and SSLCertificateKeyFile options, causing Apache to fail to start when the aegir user makes Apache reload. This is of course due to Aegir not having proper SSL certificate management yet (see #537016: simple certificate management and #394452: Full SSL support and probably others). At the moment we us a simple wildcard certificate for all sites that correspond to the wildcard hostname. This works with Apache as long as each virtualhost includes the proper configuration options so Apache doesn't crash on restart.
To make things work for us, without hacking too much, I created an ssl.conf file which contains the Apache SSL options from .drush/provision/ssl/provision_ssl.drush.inc (php_value session.cookie_secure 1 and SSLEngine On) as well as the necessary SSLCertificateFile and SSLCertificateKeyFile options (and a few others) and placed this file in the aegir config folder.
Then I modified .drush/provision/ssl/provision_ssl.drush.inc to return a single Include line to this ssl.conf file. I also had to add a line to set the config_path variable.
See my attached diff of provision_ssl.drush.inc (not sure I created the diff file right) for the exact changes. I realized my attached diff isn't really a good solution for everyone, but perhaps it will help some attempting to use the experimental SSL options available in Aegir.
I also had to include the apache.conf in a different way so that the default VirtualHost for port 443 didn't break Apache either.
Comment #6
butler360 CreditAttribution: butler360 commentedSubscribing.
Comment #7
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedfollowing
Comment #8
anarcat CreditAttribution: anarcat commentedPlease mark patches correctly when uploading, thanks for the patch.
Comment #9
timwoodSorry, I'll mark it correctly next time.
Comment #10
spangaroo CreditAttribution: spangaroo commentedfollowing
Comment #11
timwoodMy changes from patch in #5 no longer apply since provision alpha7 was released. It looks like the latest changes to provision_ssl.drush.inc (see code below) are supposed to add some options to "extra_config" and write that out to the _443 vhost configuration file, but this isn't happening on my install. All the logic up to this point appears to be the same as before. My site configuration in Aegir front-end shows the ssl and ssl_redirect options enabled, but only the ssl_redirect actions are happening. Any suggestions how to debug this? How can I make sure it's running the code below? Maybe insert a log message or something?
Comment #12
timwoodAfter a bit more digging, I'm still not sure what is going wrong with the code I referenced above in #11, but I was able to get the contents of $newoptions['extra_config'] output to my _443 vhost files by adding one line just below where the code above ends in provision_ssl.drush.inc.
I know this isn't the right way to do it, but it's working for me for now.
-Tim
Comment #13
ivanbueno CreditAttribution: ivanbueno commentedGuys, I made some updates on aegir ssl provisioning. Please review if it's useful to you:
* any server-wide certificate can now be associated to a server: http://i.imgur.com/V2zTr.png
* any site-specific certificate can now be associated to a site: http://i.imgur.com/6jKFZ.png
No manual updates to vhosts and apache.conf are needed. As long as the fields are filled in, and the certificates exist, the vhosts and apache.confs are taken care of.
I submitted a patch to the HEAD branch:
http://drupal.org/node/537016#comment-2879926
Thanks.
Comment #14
timwoodThis is a great approach and hopefully it will make it into one of the next 0.4alpha releases. Unfortunately I don't have the time or resources to test this right now. Maybe when I have a little more time I will get a chance to test it.
-Tim
Comment #15
adrian CreditAttribution: adrian commentedSSL is now completely changed.
Comment #16
adrian CreditAttribution: adrian commentedI've added IP pool management support to servers, so each server will have a list of public IP addresses configured by the admin.
In addition to this, w.r.t certificate management. SSL certificates will be identified using a textual string shortname, which will be used to determine the path to the directory containing the files.
So the server objects has an array of IP addresses available to it. I intend to add a hash table of certificates to IP addresses.
Hence, when generating the config file it will use the IP address it has associated to the ssl key ID the site has chosen. If it does not have an IP, it will try to assign one to the key and save the association for future config generations.
If it doesn't have a free IP address it will exit and the admin will then have to give the server another IP and try again.
The IP addresses associated to the site will also be saved against it, for DNS and load balancing purposes.
Comment #17
adrian CreditAttribution: adrian commentedfor next alpha
Comment #18
adrian CreditAttribution: adrian commentedgonna use this little algorithm : http://gist.github.com/474973
All the templates now use the IP address format, but for non sites they default to using '*'.
On SSL sites, the backend will override that value with the correct ip.
Comment #19
adrian CreditAttribution: adrian commentedthis is done in dev-ssl
i also did some handling of the situation where you disable ssl and we need to ensure the detritus is removed.