We're forking hosting_ssl to clean it up over in https://gitlab.com/aegir/hosting_https. The intention is to split out the self-signed certificate generation, and otherwise clean up HTTPS-support. This should allow us to have an alternative implementation available in 3.x, and a drop-in replacement in 4.x. To keep track of what we're forking, I've started aegir4_https branches in both Hosting and Provision. I've removed hosting_ssl and the nginx implementation. We'll start doing the same in Provision shortly.

Once we have a working forked implementation, I suggest that we deprecate SSL in core, to avoid having fixes committed to 3.x that don't make it into the new modules.

Comments

ergonlogic created an issue. See original summary.

ergonlogic’s picture

Issue tags: +DrupalNorth2016
ergonlogic’s picture

We're also looking at simplifying HTTPS handling in a number of ways. We intend to drop IP address handling, and re-use of certificates across sites. The former is purely cruft, and simply a source of confusion. The latter adds a bunch of complexity with minimal value. Since Lets's Encrypt support will allow HTTPS on all sites out-of-the-box, the requirement for wildcard certificates will be all but eliminated. For those needing EV certificates, the 'manual' service implementation of the Certificate service type should allow simply pasting certificates into the front-end. With deployment being that easy, I don't think re-using certificates will really be necessary.

ergonlogic’s picture

Not sharing certificates across sites also means that we really don't have to even have to keep track of certificates in the front-end. We can safely assume that the URI of the site is unique, and thus use that as 'ssl_key'.

ergonlogic’s picture

At this point, in Aegir 3.x, IP address handling is only used for HTTPS certificates. To make the transition from hosting_ssl to hosting_https easy, we should move all IP address handling into hosting_ssl.

ergonlogic’s picture

Per #5, moved IP address handling into hosting_ssl in aa0b2720

helmo’s picture

This broke a jenkins build: http://ci.aegirproject.org/job/P_Aegir_Puppet_Module_functional_test_Aeg...

PHP Fatal error:  Call to undefined function _hosting_ip_save() in /var/aegir/hostmaster-7.x-3.x/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module on line 513

Fatal error: Call to undefined function _hosting_ip_save() in /var/aegir/hostmaster-7.x-3.x/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module on line 513
Drush command terminated abnormally due to an unrecoverable error.       [error]
Error: Call to undefined function _hosting_ip_save() in
/var/aegir/hostmaster-7.x-3.x/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module,
line 513 [32.96 sec, 9.45 MB]

Adding this to server/hosting_server.module didn't help :(

include_once "../web_server/ssl/hosting.ip.inc";

So i reverted the three commits.

Jon Pugh’s picture

A lot of thoughts, now that I've had time to digest.

  • I think adding hosting_https in contrib as "experimental" is a good idea. It's the best way to test it. Hosting Pack and Cluster have been in there together for a while.
  • We need at least a few rounds of releases with hosting_https in "experimental" status before we can bump it up to be considered "recommended".
  • As a drupal module, it should have a project node page. We should do our best to keep it updated with the same code and documentation from gitlab.
  • I think starting to host stuff on gitlab is a good idea, as long as all drupal modules get pushed back to drupal.org. Does gitlab offer pushing out to other git remotes, so we could keep hosting_https on drupal.org updated?
  • Lastly, but most important: I don't think we should mark Hosting SSL module as "deprecated" right now, in a minor Aegir release. This would be quite confusing and scary to our users. The perception that we are just dropping support for a security module that's been in use for years would be bad for the project. I see no problem leaving Hosting SSL alone for now, as long as we have some decent documentation that it exists so people can enable it if they want to.
Jon Pugh’s picture

I forgot one more thing...

IP Addresses are important to some people, please don't remove this. I personally use the server node's IP addresses for automating DNS, and simply keeping track of servers.

We need the servers to have more metadata, not less.

Thanks!

ergonlogic’s picture

I don't think we should mark Hosting SSL module as "deprecated" right now, in a minor Aegir release.

We wouldn't deprecate hosting_ssl until Aegir HTTPS had proven itself. "Deprecated" does not mean "un-supported", but rather warning that we will be dropping support. And I do think this should happen in a future Aegir 3.x release, or we'll be stuck maintaining hosting_ssl throughout the 4.x cycle.

As a drupal module, it should have a project node page. We should do our best to keep it updated with the same code and documentation from gitlab.

Having a project node, and keeping the code on d.o are two separate issues. While I agree that a project node is worthwhile, mirroring code is more problematic, and doesn't bring much value. Among other reasons to move away from d.o is to simplify our release cycle, which currently involves creating release nodes on d.o across a whole bunch of projects, and can be quite time-consuming. d.o doesn't expose any APIs or other mechanisms that'd allow us to automate this process either. Not to mention semver...

IP Addresses are important to some people, please don't remove this. I personally use the server node's IP addresses for automating DNS, and simply keeping track of servers.

I'm fine with keeping IP address handling, but then I think it should be isolated in a sub-module, and split out from core. The current code is quite limited, and not actually used in Aegir core except for pre-SNI SSL.

FWIW, I usually create hostname DNS entries using an A record, then point CNAMEs at the hostname for everything else. this minimizes the need to keep track of IP addresses outside the context of the server itself.

helmo’s picture

Issue tags: +aegir-ssl
colan’s picture

helmo’s picture

Status: Active » Fixed

I've just committed a '(DEPRECATED, see hosting_https)' addition to the submodule descriptions in http://cgit.drupalcode.org/hosting/commit/?id=745d39b
And added a note to the release notes.

colan’s picture

Would it be better to say "Aegir HTTPS" instead of "hosting_https"? Not sure if folks can easily translate between machine names & human-readable names.

Jon Pugh’s picture

Does hosting_https still not allow manual certificate setup? If so I don't think we should deprecate Hosting SSL just yet.

I currently use Hosting Https but have to use the template hack to inject real certificates for some sites, because I've hit the rate limit on letsencrypt.

ergonlogic’s picture

I agree with Jon. hosting_ssl shouldn't be deprecated until hosting_https can support manually-created certificates.

I suggest that we should also test and document an upgrade path before proceeding to deprecate hosting_ssl.

helmo’s picture

Status: Fixed » Needs review

Maybe a bit too quick :(

I'll leave it out of the release notes ... but the code has already been tagged :(

helmo’s picture

Version: 7.x-4.x-dev » 7.x-3.x-dev
helmo’s picture

Status: Needs review » Needs work
helmo’s picture

I've now marked them as 'LEGACY'

colan’s picture

Issue tags: +needs documentation updates

Folks are still getting confused by the official documentation as we haven't updated it.

Jon Pugh’s picture

Changed the branch name to 2751801-ssl-remove to get auto-detected by drupal.org.

xjm’s picture

Restoring tag.