Opened 7 years ago

Last modified 7 years ago

#5561 assigned Bug/Something is broken

enable https for all MF/PL sites

Reported by: Daniel Kahn Gillmor Owned by: Daniel Kahn Gillmor
Priority: Medium Component: Tech
Keywords: https red-control-panel Cc:
Sensitive: no

Description

Now that #3668 is fixed, all mf/pl web sites should have HTTPS available by default. This means that we'll need some control panel changes, probably, as well as back-end infrastructure changes. This ticket is the overall tracking ticket for the project.

I think we want to do this by associating HTTPS decisions with each "web configuration" item in Red.

At the moment, each hosting order can have at most 2 "web configurations" -- one for https, and one for http. This should change to either:

  • 0 or more web configurations per hosting order (i.e. an arbitrary number), or
  • 0 or 1 web configurations per hosting order

Each web configuration should know its preferred domain name and have a list of aliases.

Each web configuration should default to using its own secret key, and should start out with a certificate certified by the MF/PL certificate authority.

The web configuration apache config would be used to create a port 443 vhost stanza with the appropriate pointers.

Each web configuration should have a single checkbox choice of "enforce HTTPS". Checking this box would make a port 80 vhost stanza that contains only mod_rewrite-based canonicalization to the https version of the site. Leaving the box unchecked would make a port 80 vhost stanza that contains the same content as the port 443 stanza (without the mod_ssl directives, of course).

Each web configuration in the control panel should link to a well-formed CSR so the member can send the CSR to their CA of choice (if they decide they don't want to use the MF/PL CA).

The member ought to be able to upload a new signed certificate request directly via the control panel, which will be checked for validity by the host before being accepted.

If implemented, this proposal should also end up resolving #407.

Change History (4)

comment:1 Changed 7 years ago by Daniel Kahn Gillmor

note that members with any significant part of their userbase stuck using IE on WinXP may still want to request a separate IP address for their site if they make heavy use of HTTPS, since IE on WinXP fails at SNI.

comment:2 Changed 7 years ago by Daniel Kahn Gillmor

Status: newassigned

I've been thinking about next steps for this, and have put up the start of some detailed technical background for the first steps. I'd be grateful for any review, feedback, criticism, or suggested improvements.

Last edited 7 years ago by Daniel Kahn Gillmor (previous) (diff)

comment:3 Changed 7 years ago by Jamie McClelland

Nice work dkg.

I think it's a good approach.

I have only one structural concern and suggestion - which is the location of the csr/crt/keys, specifically with regard to moving sites from one server to another.

Each hosting order has a .red directory in it's root directory that is root-owned and contains files not intended for direct user control (that's where the apache configuration file lives, awstats data, etc.). I think this might be a better place for the csr/crt/key files to live for each hosting order. That when, when a hosting order is moved (and the entire hosting order directory is copied to a new server) we're sure to have all the proper files.

When a hosting order is moved to a new server it will always have the same absolute path, so we don't have to worry about making any changes.

I like the iframe solution for displaying CSR's to users!

comment:4 Changed 7 years ago by Daniel Kahn Gillmor

that sounds like a reasonable proposal, jamie. Could you update wiki:https-for-all with the change of paths?

Any suggestions for how to integrate the key/cert/csr/iCA triage tools with red?

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.