Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.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
Comment #2
ergonlogicComment #3
ergonlogicWe'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.
Comment #4
ergonlogicNot 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'.
Comment #5
ergonlogicAt 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.
Comment #6
ergonlogicPer #5, moved IP address handling into hosting_ssl in aa0b2720
Comment #7
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedThis broke a jenkins build: http://ci.aegirproject.org/job/P_Aegir_Puppet_Module_functional_test_Aeg...
Adding this to server/hosting_server.module didn't help :(
So i reverted the three commits.
Comment #8
Jon PughA lot of thoughts, now that I've had time to digest.
Comment #9
Jon PughI 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!
Comment #10
ergonlogicWe 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.
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...
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.
Comment #11
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedComment #12
colanComment #13
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedI'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.
Comment #14
colanWould it be better to say "Aegir HTTPS" instead of "hosting_https"? Not sure if folks can easily translate between machine names & human-readable names.
Comment #15
Jon PughDoes 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.
Comment #16
ergonlogicI 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.
Comment #17
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedMaybe a bit too quick :(
I'll leave it out of the release notes ... but the code has already been tagged :(
Comment #18
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedFor reference, the two 'blockers' here are #2936037: Add a 'manual' Certificate implementation and #2936039: Per site certificate service on a server
Comment #19
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedComment #20
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commentedI've now marked them as 'LEGACY'
Comment #21
colanFolks are still getting confused by the official documentation as we haven't updated it.
Comment #22
Jon PughChanged the branch name to 2751801-ssl-remove to get auto-detected by drupal.org.
Comment #23
xjmRestoring tag.