Full SSL support

Note that we could have a module to automatically 'resell' SSL certs too..

Hi,

I haven't tried the appliance. Looks interesting.

As for the API, what you are mentioning goes further than "just SSL": those are APIs to provision complete virtual servers.

As for Gandi.net, yes, good: they provide free SSL certs, unfortunatly, their API doesn't seem to support SSL yet (although it's planned, apparently).

As for this issue in particular, I would like to keep it to provisionning existing SSH certificates under apache (or other systems, later). Interfacing with providers should be a separate issue, for which this implementation could provide an API.

This would be how I would see this working:

Certificate management on the frontend

We first would need a "SSL certificate" content type. That would be a simple node type in which the body would hold the .pem file (which includes the private SSL part, unencrypted, so that's already a security issue). Certificates would therefore be managed as any content in Aegir, using appropriate client-based permissions (as sites are). All this would be handled in the hosting frontend.

Storing certs on the server

You could then associate sites with SSL certificates. Once you do that, the SSL certificate would be pushed to the relevant server and be associated with it. There should be an on-disk SSL certificate storage in ~aegir/$CONFIG/ssl.d (e.g. /var/aegir/config/ssl.d in a standard configuration). This would need to be performed by the provision backend.

Configuring vhosts

Another thing that will need to be performed by the backend is the vhost configuration. This would hook into the regular vhost apache hooks (i don't remember the name) to add a few configuration settings to the apache config file:

        SSLEnable
        SSLRequireSSL
        SSLCertificateFile /var/aegir/config/ssl.d/fqdn.example.com.pem

The vhost port would also need to be changed (see #515052: Customizable port field per site for more info on this issue, which SSL depends upon IMO).

Extra: dual http/https configuration options

Finally, there could be a setting in the frontend to do one of those:

1. configure the vhost as SSL only (ie. no HTTP)
2. configure redirection to SSL (ie. HTTP redirects to HTTPs, so this requires a redirection vhost)
3. configure both SSL and non-SSL (both vhosts configured normally)

This may require more extensive changes to the way the vhost files are generated now.

Extra: non-stored SSL configuration

For more security, the certificates may be installed out of band by administrators and not stored in the database. Then we would need a setting in the frontend that would just tell the backend to configure the vhost, but not manage the cert files.

Extra: parsing certificates

The uploaded certificates could be parsed for domain application and expiration dates, which could be exposed in the node for sorting and detecting expired certificates, or finding the right certificate for your domain.

Extra: chained certificates

We could have dependencies between certiticates to allow chained certificates (like the Gandi/Comodo one) to work out of the box. Right now, we work around this issue by just adding this configuration setting system-wide:

SSLCACertificateFile /etc/ssl/gandi.intermediate.pem

... but this will not work in the generic case.

Pound and other LB support

Then of course we could support other systems of load balancing, which should be a separate module. Care should be taken to abstract the Apache configuration in the above development to make this not too hard.

I wrote a a post to the group to seek discussion, so please keep to the spec or patches when discussing here.

Note that we should probably add a "enforce" flag that would redirect the non-ssl site to the SSL version. The cleanest way to do this is in the vhost:

<VirtualHost *:80>
  DocumentRoot /var/aegir/drupal-5.18-aegir

  ServerName aegir.koumbit.net

  Redirect / https://aegir.koumbit.net/

# Extra configuration from modules:

    # Error handler for Drupal > 4.6.7
    <Directory "/var/aegir/drupal-5.18-aegir/sites/default/files">
      SetHandler This_is_a_Drupal_security_line_do_not_remove
    </Directory>

</VirtualHost>

Then the SSL site looks something like this:

<VirtualHost *:443>
    SSLEngine On
    ServerAdmin webmaster@localhost
    ServerName aegir.koumbit.net

    DocumentRoot /var/aegir/drupal-5.18-aegir

   php_value session.cookie_secure 1
# Extra configuration from modules:

    # Error handler for Drupal > 4.6.7
    <Directory "/var/aegir/drupal-5.18-aegir/sites/default/files">
      SetHandler This_is_a_Drupal_security_line_do_not_remove
    </Directory>

</VirtualHost>

cookie_secure is important to prevent session hijacking.

I think I can now summarize the discussions that took place on that groups post..

1. we'll abstract away the Load balancers and other other webservers, while keep an open mind in supporting those: we focus on Apache provisionning for now, but stay extensible
2. we need to manage certificates independently of the sites: one certificate may service multiple sites (for example with wildcard certificates), although we can start with one to one relationship, that needs to be extensible too
3. we need to parse certificates to figure out which domains they can service and pass that back to the frontend so it can offer proper choices to the user. that's not a blocker, as it depends on multi-site certificates
4. we agreed that certificates can be stored in the database or the filesystem. "certificate" nodes could contain the certificate in the node body or a path to a certificate that would be stored on the central server (or distributed, that remains to be defined)
5. what uniquely identifies a certificate is the certificate hash as generated by OpenSSL. if there are common SSL certificate spools, that ID can be used to reference the certificate instead of an absolute path
6. we have a draft API to start with
7. SSL provider integration will interoperate with that API, not a blocker either

All that should be the basis of a new provision_ssl module that could be developped for 0.4. Basically, a first spike would consist of:

step 1: #537004: "SSL site" option, which implies:
* backend: hooks to configure vhosts as above
* frontend: form_alter the site form to add an SSL option
* this would abstract the certificate management for now, which would mean a single certificate for the whole server

step 2: file-based certificate management, 1 to 1 management, which implies:
* backend: #537016: simple certificate management
* a common SSL spool (~/config/ssl.d?) on the central server
* resolve multi-server support issue (ie. do we store the SSL certs on only one server or distribute?)
* generate hash symlinks for certificates using SSL and pass that to the frontend
* this would all be part of "server verification" (which is currently platform verification)
* answer frontend requests to associate site X with cert Y
* frontend: #537020: create SSL certificate content type
* collect certificate information (per server?) in certificate nodes which keep the certificate path and ID
* site/certificate 1 to 1 association
* certificate access controls (client based?)

step 3: all the rest: #537028: user-supplied certificates, #537022: domain-restricted certificates, #537032: wildcard and multi-domain certificate support (n to n).

* backend:
* parse certificates for domain information, pass that to frontend
* write certificates passed by the frontend
* frontend:
* add certificate fields for domain information
* certificate selection based on site domain name
* N to 1 cert/site association
* allow users to submit their certificates

I will create subtasks for all of those, this will become the "master" tracking task.

tagging

work has started on the "ssl" branch in git, and #537004: "SSL site" option has been committed, although it needs #570980: allow vhosts of the same name on a different port and #541754: abstract away vhost engine (so that we can make http -> https redirections).