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.

CommentFileSizeAuthor
#5 provision_ssl_drush_inc.txt893 bytestimwood
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

anarcat’s picture

Issue tags: -ssl +aegir-ssl
anarcat’s picture

This 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

timwood’s picture

anarcat,
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.

anarcat’s picture

I am aware of that. What I am saying here is that apache yields a warning and sometimes has unexpected behavior when doing that.

timwood’s picture

FileSize
893 bytes

My 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.

<IfModule mod_ssl.c>
        php_value session.cookie_secure 1
        SSLEngine on
        SSLCertificateFile    /etc/ssl/certs/star.example.com.crt
        SSLCertificateKeyFile /etc/ssl/private/star.example.com.key
</IfModule>

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.

butler360’s picture

Subscribing.

SocialNicheGuru’s picture

following

anarcat’s picture

Status: Active » Needs review

Please mark patches correctly when uploading, thanks for the patch.

timwood’s picture

Sorry, I'll mark it correctly next time.

spangaroo’s picture

following

timwood’s picture

My 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?

    $newoptions = $options;
    $newoptions['site_port'] = 443;
    $newoptions['extra_config'] = "php_value session.cookie_secure 1\nSSLEngine On\n";
    provision_write_config(drush_get_option('vhost_path') . '/' . $url .  '_443', _provision_apache_default_template(), $newoptions);
timwood’s picture

After 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.

return array($newoptions['extra_config']);

I know this isn't the right way to do it, but it's working for me for now.

-Tim

ivanbueno’s picture

Guys, 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.

timwood’s picture

This 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

adrian’s picture

Status: Needs review » Needs work

SSL is now completely changed.

adrian’s picture

Title: SSL provisionning with multiple vhosts fails » Assign IP to virtual host based on SSL certificate chosen.

I'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.

adrian’s picture

Category: bug » task
Priority: Normal » Critical

for next alpha

adrian’s picture

gonna 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.

adrian’s picture

Status: Needs work » Fixed

this 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.

Status: Fixed » Closed (fixed)
Issue tags: -aegir-ssl

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 6d1b8c7 on debian, dev-dns, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-simplerinstaller, dev-ssl, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by adrian:
    Assign unique ip addresses for each of the certificates. #712958
    
    I use...