simple certificate management

I had Aegir installed in Ubuntu 9.10 and needed to have server-wide and site-specific certificates. I had to add some more patches in addition to anarcat's patches above.

Here's how I did it:

Create a server-wide certificate

• Create a dir where certificates will live: mkdir /var/aegir/config/ssl.d
• Create the server-wide certificate
• it's name should be web-host-name.key, web-host-name.pem
• in this example, the server name is aegir.local
• openssl req -new -x509 -days 365 -nodes -out /var/aegir/config/ssl.d/aegir.local.pem -keyout /var/aegir/config/ssl.d/aegir.local.key
• Enable the ssl module for apache
• sudo a2enmod ssl

Create a site-specific certificate

• In this example, the site names are site1.local, site2.local
• put the certificates in ssl.d:
• site1.local.pem, site1.local.key
• site2.local.pem, site2.local.key

Update aegir.conf

• add this inside of /var/aegir/config/aegir.conf:

      SSLEngine On
      SSLCertificateFile /var/aegir/config/ssl.d/<Your-server-wide-cert>.pem
      SSLCertificateKeyFile /var/aegir/config/ssl.d/<Your-server-wide-cert>.key
  

Apply the patches attached below.

• ssl.hosting.patch
• ssl.provision.patch

Update drupal
a new column is added to an aegir table

Configure aegir

• Enable the aegir ssl module
• Make sure the SSL feature is enabled.
• In aegir, got to server tab, and edit the server-site:
• Add 443 to its ports

Create a site with https

• When you create a site under that server, you will now have 3 options:
• Enable SSL encryption
• Use server-wide wildcard certificate
• Redirect HTTP to HTTPS
• Make sure that site has a certificate in ssl.d

Hi,

I updated the patch to work with the head for provision and hostmaster. (See attached files.)

In order for the patch to work, it assumes the following:

* All the certificates are stored in $AEGIR_HOME/config/ssl.d/
* The certs key and pem files are named with the server domain name or the site domain name. For example, for a server named aegir.local, its certificates are aegir.local.key and aegir.local.pem. For a site called site1.local, its certificates should be named site1.local.key and site1.local.pem, located inside /var/aegir/config/ssl.d/

After applying the patch, do a drupal update: a new column (ssl_wildcard) gets added to hosting_site table. It's a flag whether a site should use a server-wide certificate or its own certificate.

Thanks.

--Ivan

...changing version to HEAD.

Hi,

Please disregard the patches above (http://drupal.org/node/537016#comment-2874306), and use the patches below instead. I made some updates:

* In the Server node, any certificate can now be associated to a "server": http://i.imgur.com/V2zTr.png
* In the Site node, any site-specific certificate can now be associated to a "site": http://i.imgur.com/6jKFZ.png . If the "use server-wide certificate" is checked, it will used the cert associated to the server instead.

Updating steps...
* After applying the patch, please do a drupal update.
* Under server, add 443 to the ports
* Under server, add the absolute path of the server-wide certificate associated to the server
* Under site, select port 443 and select "Use server-wide certificate" or enter the unique certificates associated to site.

Thanks.

--Ivan

Fixed a bug in the patch. Please use the attached files below.

Patches apply cleanly.

You'd think twice about applying this until #578048: Customizable IP address in vhost file because a) ssl only has limited usage until you can have multiple signed SSL certs, and 2) you would probably have to refactor this stuff afterwards anyway.

Oh, patches apply cleanly AND it works as advertised.

I'm using .4alpha7 so it might not apply to head...

This patch has been applied to HEAD as of the post date:
http://drupal.org/node/537016#comment-2892782

So it should work, (unless there are changes in head since then that could invalidate the patch).

I am extremely happy to report that this is working great for me on .4alpha7! It is a bit confusing that you must choose port 80 or 443 rather than both, but choosing 443 creates a site that works via http and https, 80 and 443. strangely, if you click on the site in aegir, it shows as port 443 but if you click on edit, it then shows port 80. Even works with Secure pages/prevent hijack if you comment out cookie.secure in the site's _443 file in vhost.d as in http://drupal.org/node/695594 (I realize this is a questionable practice but seems to be necessary for the important functionality SP provides).

Anyway, thank you a ton, anarcat for getting it started and ivanbueno for putting it all together! Would love to see this rolled into the next aegir alpha, whenever that happens. Had to patch by hand as I was having trouble with using the patch command with these files. A bit tedious but worked in the end.

This is good work, and I am looking forward to finally getting this problem solved.

Unfortunately this patch comes in the middle of a sprint on the new multi-server work in aegir. (see the dev-services branch: http://git.aegirproject.org/?p=provision.git;a=shortlog;h=refs/heads/dev...).

This branch is a major rewrite of the backend, and almost all of the files you modified for this patch no longer exists in the new codebase.

The 'web_server/provision_apache.drush.inc' file no longer exists for instance, instead being replaced by a general case "http" service,
that has apache as one of it's implementations (http://git.aegirproject.org/?p=provision.git;a=tree;f=http;h=889cd755caf...)

This branch is due to be merged into the master branch very shortly, and because all of this refactoring has already occurred, it would unfortunately orphan your changes.

It's not all hopeless though, as the new branch was specifically designed to allow us to implement features such as these more cleanly. Because APACHE is just a type of http service, we should look at the possibility of having APACHE_SSL be a service too. This would resolve a lot of the port weirdness we have found before. We also abstracted the config file generation into classes, which will significantly simplify the SSL vhost generation.

So i'm really sorry that I have to turn down your contribution, which i do really appreciate, but it's not the right time for it to go in. If we did commit it, the functionality would break immediately, and then need to be rewritten to follow the new api.

This feature is pretty high on my todo list though, so if you are willing to stick around for a bit we should be able to get something into our next release.

I'd love to make this work for the dev-services branch. I just need to familiarize myself with it. Hopefully for those not ready yet to upgrade to the next release, this patch can be useful.

As I mentioned, it works great for me. Really hope this functionality can be worked into the next release! Some notes though, and I'm sure they'll be dealt with once this is all worked into the refactored Aegir of the future -- sites with ssl turned on using this method cannot be cloned. Comes up with an error about not being able to find the site-wide certificate or somesuch. To clone, I've had to turn off ssl (and in my case not only disable Secure Pages but also turn off the module or else it gets all confused) and then do the clone. But considering that I was having a heck of a time just making ssl work on multiple aegir sites and these patches make that happen, I'm very grateful even if there are flaws at this point. For that reason, I'll be sticking with this patched version for a while, and watching anxiously as Aegir progresses.

the new architecture is in the master branch now, for people following at home.

regarding the ssl wildcard setting.

I would like to have the SSL functionality implemented as a sub class of the base web server service.

ie: when you configure the server you select either Apache, or Apache +SSL.

In the site configuration, Instead of having to choose 443 as the site port, you should just have the 'enable SSL' , which implies it will be hosted on 443.
This 'enable_ssl' could be where we store the value of the wildcard.

ie: if it's 1 , you use the site specific cert. If it's 2 you use the server wide cert.

I also dont think it should be configurable from the UI. In my mind we should just look in a certain place for the cert, and if it's not found create our own.

This will allow the admins to simply place their certs in the right location should they want to use their own.

Adrian has outlined some requirements here, so here is a link to my analysis of problems (as at alpha7).
#793300: Refactor vhosts for SSL/IP support
I'm going to close that issue to reduce queue noise, and point it back to here.

So my idea for this is to just generate the certs automatically in the backend and leave it up to the admin to replace the files.

Additionally, having site level certs is entirely irrelevant until we get IP pool management : http://drupal.org/node/836166

So the only thing we can really do is provide a server level certificate and turn it on for sites correctly. This will cause complaints, unless you get a wildcard cert and you only give out sites in that domain.

http://skitch.com/vertice/dj8a2/google-chrome
http://skitch.com/vertice/dj82e/adrian-ubuntu-projects-hosting-config-ss...

So we have a problem in the new architecture in that we can't rely on absolute paths, because the actual path to the key file on each server will be different.

So how i want to handle the key management is that when you create a new site you just enter a machine name / identifier for the key.
This will be a component of a path, ie :
$aegir_root/config/ssl.d/$SSL_KEY/ssl.key
$aegir_root/config/ssl.d/$SSL_KEY/ssl.crt

Say for example "somedomain_wildcard" or even just "somedomain.com".

Instead of adding a new cert, you can also from the drop down select one of the certs previously added by your client.

I'm looking into generating a self signed cert automatically in the case none is found, so that we can always rely on SOME certificate being there.

Therefor, installing your own cert would be scp'ing it into the designated location on the server either before or after the site has been created.

Generating a self signed crt - http://gist.github.com/459414

I'm doing it this way because the workflow of just replacing it with the real certificate is simpler than the workflow of trying to determine if it's there in the first place. We should still probably warn the client about the self signed cert.

For next alpha

This is nearly done on the UI side.

1) Creating a new site - http://skitch.com/vertice/dc8w8/create-site-t-4
2) Viewing an SSL enabled site - http://skitch.com/vertice/dc8u3/newform.dev-t
3) Editing existing SSL enabled site - http://skitch.com/vertice/dc8wf/newform.dev-t

It's all in the dev-ssl branch of the hostmaster project.

I'm still working on the provision side of things, but atleast the functional design there is done.
I'm just having trouble figuring out how to structure this functionality for the best possible re-use.

The majority of the SSL functionality is going to be re-usable for the nginx +ssl and so forth services.

Looks extremely good! Is there the possibility of running ssl and non-ssl simultaneously for a domain?

see http://skitch.com/vertice/dc8w8/create-site-t-4

when it's enabled, you are running both http and https.
when it's required, it will redirect http to https.

it's explained in the field description.

And this is now done in dev-ssl.

I have it generating new keys automagically, and the synch is working.