move the SSL IP allocation to the frontend

Also, we should allow to use the same IP for many SSL enabled sites, to support TLS SNI (not sure about Apache, but it works in Nginx). I had a patch for this somewhere, but it was for Nginx only.

Apache TLS SNI appears to be working for me.

Hi,

I have ran across this while configuring Aegir to support SSL with Service Alternate Names (SANs). Aegir out of the box does not support this because it enforces one IP address per SSL certificate. Once you add more than 1 SSL enabled site, per IP, managed by Aegir, SSL support fails.

This is avoided by not enforcing one site per IP, though this I imagine will cause issues for non SAN SSL certificates.

I was thinking that keeping SSL IP address allocation as it is would be proper, and in addition, exposing an option per site to enable SAN. With this option selected, the check for the IP address in the assign_certificate_ip method would be avoided.

The first attached patch allows for multiple sites to listen on port 443, rather than stuffing a single IP per site into the conf file. This is a temporary solution, as a proper one will recognize the site as SAN enabled, and then change the IP address to *.

The second patch simply comments out the function that checks for a free IP address. I plan on extending this by exposing SANs per site as outlined above, so that the original function can be used in the applicable situations.

Does this sound reasonable or are there pitfalls that I am not anticipating?

Thanks

I am not sure what the issue tags are for. If that means this project is moving forward, that's great.

I am working on my SANs module and am curious about how to hook into the existing SSL files. I would like to modify the code based on whether or not the module is enabled. Can I do this with a hook or must I hardcode it into the existing code like this?

(san is the name of the module thus far)

<?php if ($this->san_enabled): ?>

	<?php foreach ($server->ip_addresses as $ip) : ?>
		NameVirtualHost <?php print "*:" . $http_ssl_port . "\n"; ?>
	<?php endforeach; ?>

<?php else: ?>
		<?php foreach ($server->ip_addresses as $ip) : ?>
			NameVirtualHost <?php print $ip . ":" . $http_ssl_port . "\n"; ?>
		<?php endforeach; ?>

<?php endif; ?>

/**
* Not needed for our RedHat Box which has SSL enabled but is checked after this module, thus throwing an annoying *warning upon httpd restart. 
*/

#<IfModule !ssl_module>
#  LoadModule ssl_module modules/mod_ssl.so
#</IfModule>

The API for the functions is great, but I am not aware of how to override the classes like this one, http://api.aegirproject.org/api/Provision/http--http.ssl.inc/function/pr...
Any tips or guidance would be appreciated. Thanks.

I would absolutely support manual IP address management in the front end or at the very least remove the "automation" practices in provision to make it a more manual and reliable assignment process.. In my current testing I am getting all sorts of strange results like multiple ssl sites on a single IP or multiple IP's showing in the frontend for non-ssl sites with no corresponding Apache directives for the vhost configs..

These issues are far too dangerous to ignore.. Imagine if IP's for a site are changed by the Aegir/provision automatic IP assignment logic and suddenly a domain is resolving to a competitors site?? The fallout would be massive..

For what its worth my suggestions are as follows..

1) By all means maintain a list of IP's on the server in the front end.. Something like it is now is fine but the IP's are not configured in any Apache directives at server level.. It is simply a list of available IP's..

2) Apache IP related directives (eg VirtualHost etc..) should ONLY be specified in the vhost config files.. Not at server or platform levels.. This will reduce the NameVirtualHost warning messages when restarting Apache where unused IP's are associated with a server but not with a site.. It will also mean its all cleaned up properly when a site is deleted..

3) IP addresses are manually assigned at site level when creating or editing an ssl site..

4) A single IP to site mapping table/file would probably be the best way to record the IP assignments which would allow continued functionality in the backend and better control in the frontend.. The administrator could quickly see which IP addresses are used and where or which IP addresses are available..

Obviously there are knock on issues that would need to be addresses, for example defining front end access and permissions to assign IP addresses to sites but I feel that this process is critical and MUST be correct to avoid downtime or misconfiguration of sites..

There is some crossover here with my other thread here http://drupal.org/node/1355856 where I feel that Aegir/Provision should ONLY define vhosts and not try and take over the Apache server meaning its will be more compatible with running other sites and systems on the same server and will make implementation for sysadmins far simpler and less risky..

I have patches for Apache (http.ssl.inc and the templates) ....

As soon as I've got a sandbox, I'll post our patches (or a branch?)

this is almost exactly what we've done. As far as I'm aware, there is no reason not to 'mix' and match ip assigned and non-assigned virtualhosts. The ServerName directive is always in place (for sni) and the ip assigned virtuals are unambiguous.

Am I missing something? I haven't tested it yet.

There seem to be two parts to this process if it is to be 'easy' for the 1.x branch and 'complete' for the 2 branch.

As it is now to support 1.x

1. adding the field ip to hostmaster_site (node and form api additions)
2. modifying the http.ssl.inc (obtain ip from site_config instead of lock file)
3. adding the case/switch to the templates (4 in total)

Whereby 3 also needs to be done for nginx.

Seems easy enough to me. The 'server' module needs to be refactored later but would not get in the way, as far as I can see.

The only point at which hostings server ip assignment and the deployment of ssl now interact is in the http.ssl.inc provisionService_http_ssl class

$ip = provisionService_http_ssl::assign_certificate_ip($ssl_key, $this->server);

obtaining ip from if $this->context-> instead doesn't appear to have a penalty. And it doesn't effect the creation of certificates either.

In any case, because of the need to override the templates in 1.x (http://drupal.org/node/1356150), we're doing this in production with no problems accross a number of platforms and profiles.

I'd like to push our code (we're also now in a sandbox with an LDAP AUTH module for hostmaster) into a sanbox ... where?

Greetings,
Mark

Hi Mark,

Your work sounds promising. Have you had any experience using a wildcard in your IP address allocation for SSL? That is what we are currently doing because of how we support Service Alternate Names.

"1. adding the field ip to hostmaster_site (node and form api additions)"
Would this be a dropdown with IP addresses that Aegir is aware of or a text box which would allow for any IP address to be submitted?

As wipeout_dude mentioned above #6, SSL needs to be handled with care. Aegir in the end needs to maintain the robustness and rollback features that make it such a great hosting management tool.

I would be interested in looking at your patches. Can you put them on bitbucket or github?

Many thanks.

What we're doing depends on sni. That is, all virtuals are presently *:443.

What we do is extend the site creation form (node_form) and add the ip field. If it's present (for a site node) we use it in the vhost.tpl.php. If not, fallback to the ip address. AND we override a method in http.ssl.inc.

There are no problems with rollbacks, creation of certs, deletions of certs and the like.

What we have NOT tested is the deployment to other (cluster web heads) and I'm now testing the mixing of IP and SNI virtuals.

It's not, strictly speaking even necessary to pay any attention to the list of ip addresses as long as the one function in http.ssl.inc is overridden
$ip = provisionService_http_ssl::assign_certificate_ip($ssl_key, $this->server);

Is the relevant function. What I'm writing at the moment utilizes the existing hosting_ip methods (utility methods from the core hosting modules) to re-use the tables. That'll take me till friday to have ready.

In the long term, a bunch of code needs to be refactored out since it's overdeterministic (can such a thing happen!!:) but it's not really of consequence (at least I'm not seeing any errors with day to day provisioning/backups/deletes, etc)....

I should have some code to post friday (I'm testing on production clones to see what happens with real-world platforms)...

As far as #6 is concerned, the RULE is ONLY assign an IP address if one has been fixed for this site. It is a static value which is not obtained from a pool or otherwise acted upon. Create a site. Enter the IP address. One is found, it is used (provisionConfig_http_ssl). Otherwise, wildcard.

That's the way it should be :)

I just looked at the code you posted and that's what we did originally (pushed the modified sources to our deployments using puppet), not even supporting ip based virtuals at all.

blueprint, any code to share? I like your idea but I am having a difficult time testing the changes you have made without seeing much of the code. Currently, my approach works for everything except migrations between platforms, yet your approach, you say is solid. I would like that peace of mind as well.

Thank you for your continued effort in improving virtual SSL support.

Sorry about the delay! I'm a sysadmin, so drupal is only a small part of my job:

http://drupal.org/sandbox/blueprint/1331024

is my sandbox with our aegir ldap auth (creates a form on site add for added ldap auth for apache configs). There I have included all the 'hacked' aegir configs (overriding /usr/share/drush/commands/provision 'stuff').

I'm still looking at a module approach, but, frankly as long as I'm using the aegir packages (debian from the aegir project) ... I must write over some of the package files anyway (I use puppet which checks the consequences of package installs and replaces files the packages have modified from a list that 'they shouldn't).

In any case, if I get back to it any time soon, i'll try to let you know. It's a bit of a 'should move to core' thing, though....

Thanks for the repo. I found the code down there in the /usr directory. I will diff it against mine on Monday. I appreciate you sharing your findings and agree it should be something moved into core or as an add on to Aegir if appropriate.

I will post my test results here and hope to have it into production soon. My current system for the SSL is fairly robust but it has a hard time with migrations.

We accomplished the same workaround but with different methods. :)

I created a blueprint branch in my aegir install and ran your modified code, I run into the same problem but running your version made me aware of this.

My main hostmaster install manages several remote servers and I only have issues when I need to migrate between platforms. I believe this is caused by my wonky symlinks to files that do not exist on the central hostmaster. http://community.aegirproject.org/node/29/talk#comment-1136 mentions the symlink setup I use. I am going to try a few things out but I do feel progress has been made and I am closer to a solid implementation.

Thanks again blueprint.

All right, I have made progress.

For simplicity, I will propose this as my Aegir infrastructure.

=========
||Aegir Hub ||
=========
|
|
==================
|| Remote Production Host ||
==================

The major inconvenience I continued to run into with my original alterations and blueprints version was that Aegir refused to copy the openssl.key and openssl.crt files from the Aegir Hub because they are symlinks to a destination on the remote server, not the Aegir hub. I have made these symlinks. Please see http://community.aegirproject.org/node/29/talk#comment-1136 for further background information.

When these files are not copied properly, apache then flips out and refuses to restart until those files are in place. Until now I have been moving the files by hand on the remote server, restarting apache, and then doing the same on my Aegir hub and verifying the site.

A solution that appears to work so far is to place bogus files on the Aegir hub so that the symlinks point to files, even though they do not contain the crt or key contents, and this seems to solve the issue. The files are copied and apache restarts successfully.

What is odd is that Aegir complains that the files, prior to the bogus files being in place, do not exist in the directory config/ssl.d/sitename. Once the site migrates to a new platform on the remote server, that directory is irrelevant as the ssl configurations are all stored in /var/aegir/config/servername/ssl.d/sitename. These particular files never have a problem during migrations.

My question is, why does Aegir care about the files in /config/ssl.d/sitename when they are not used on the remote host? Is this something that pertains to dedicated IP addresses per SSL certificate and not our Service Alternate Name configuration?

Great job spearheading this anarcat. My work has diverged from Aegir for a few months but I do want to help with this issue as I am sure I and others will run into it again.

Allowing a site to be mapped to a specific certificate would be great. That is kind of what happens now when you enable SSL on a site within Aegir.

Currently when Aegir creates a certificate we replace the contents of the created SSL directory in /var/aegir/config/server_name/ssl.d with symbolic links to our actual certificates. If we could specify the path to the certificates in the Aegir frontend it would negate the need to manipulate the generated SSL certificates.

If a person has 4 sites on a platform that exists on a server with an SSL certificate the user might want 2 of the sites to not use SSL so they would turn SSL off on those sites within Aegir. However, the other 2 sites might be listed on the certificate with a Service Alternate Name so each site should be able to reference that one certificate.

I guess that means I support your thinking that there should be a site/certificate association but not necessarily an IP/site association. It seems like the thinking back in comment #12 supports this line of thought as well.

I'll try to grab the dev branch and test it on a vm to see those changes you mention. Great work!

Great progress anarcat. Thanks for the updates.

Sorry, I'm slightly confused about how the IP's are allocated on the front-end now.

A new Certificates tab is now available in servers to see the SSL certificates used on a given server. This also details the IP allocation associated with those certificates.

So, you somehow specify the IP when you provide Aegir with the SSL cert? What way are IPs selected then for self-signed certs that Aegir generates?

Thanks,
Paul.

Ok, if I've understood correctly, a good test would be to

git clone --branch dev-ssl-ip-allocation-refactor http://git.drupal.org/project/hostmaster.git

and test with, for instance, san certificates, multiple domains on one ip, etc? I'm not certain if allocation in the frontend permits wildcards? (we've got a number of cases where we have a client with a san and 5 or 6 domains on a single ip)....

THANKS for your great work!