Feature: Add HTTPS Option

[linknum23]

Follow steps at https://github.com/DrMint/Intranet-Lets-Encrypt-Certification It looks something like this:

• [ ] Give amplipi.com an https cert
• [ ] Make local only subdomain ie: local.amplipi.com

[linknum23]

Looking back it would be nice to add the option to add a certificate to the AmpliPi interface without exposing it to the web. This may be an advanced configuration initially.

[zjs]

Perhaps you could also consider ACME integration for use with Let's Encrypt or step-ca?

In the meantime: is there a recommended workaround for adding a certificate? (Happy to follow directions to SSH in and muck with stuff.)

[linknum23]

The steps in the issue summary above assume an ACME-like integration. I'll add a separate issue for simply uploading a certificate to enable HTTPS.

EDIT: Check out #354

[rtertiaer]

There's a lot of complication around this idea. I'm unconvinced it is workable.

• To issue a certificate for a particular name, a CA needs to validate ownership. There can be no ownership of amplipi.local - it's local :)
• Along those same lines, certificates cannot be issued for private IPs.
• Amplipi boxes should not be exposed to the public internet; straight LetsEncrypt is a non-starter (though it looks like you've already arrived at that conclusion.)
• There are security concerns around shipping a public+private key to the world that's valid for an amplipi.com (sub/)domain:
  • Doing what is described in the issue description for AmpliPi would be more or less useless for privacy and authentication - we'd be shipping the private key for that certificate publicly with our images and software (not to mention it would need to be updated every 2mos or so.)
  • We potentially open ourselves up to funny little CORS and Cookie things; see the below notes on user-supplied DNS records.
• Even if users supplied their own domain name that points to an internal IP, this can have some less than ideal implications for security, particularly around CORS and cookies. Example: with a DNS A record for a.myname.com -> 10.20.30.40, there's a small but present risk an attacker that can control a different 10.20.30.40 can abuse less secure CORS and cookie settings on myname.com to access privileged data or send data in privileged ways (I'm thinking of all the myriad of other self-hosted services that do not do a great job locking down CORS or Cookie settings.) I don't think we should be encouraging users to create these types of records (though I could definitely still see this being an advanced option with nice warnings around this behavior, a la #354 .)

[zjs]

The way I use certificates for other internal systems is roughly as follows:

• I have a subdomain I use for my local network (e.g., local.example.com). These addresses only resolve on the local network.
• I get certificates from Let's Encrypt using a DNS challenge (e.g., for amplipi.local.example.com).
• I give the internal system an API key for my DNS provider, so that an ACME client can make a DNS-01 challenge (e.g., setting the TXT record for _acme-challenge.amplipi.local.example.com).

I think this avoids the issues: certificates are issued for subdomains I own, certificates are not issued for private IP addresses, my internal systems are not publicly exposed, the private key never leaves the system for which it was generated, and the subdomain is only routable within my local network so CORS and cookies issues aren't relevant.

[rtertiaer]

Howdy Zach - Cheers on your input :) I think your use-case is possibly better suited for #354 , which I think is worthwhile to implement for cases like yours; that same script of yours that gets a new cert via DNS challenge can also use the AmpliPi's API to supply its new cert :smile_cat:

My understanding of this particular ticket was to automate the process of setting up HTTPS end to end, which seems infeasible for the reasons describe above. To use your workflow as an example, not simply programming but also supporting multiple DNS provider's APIs and creating a bit of glue for ACME clients feels a bit out of scope for the project with the current amount of development resources we have available. However should you come up with a generic implementation here we would absolutely welcome your PR!

If you do continue down that path: you can install new system software by adding it to scripts/configure.py, which is run during every install/update process. #549 might be a good example PR of installing system software, creating a slim API call to manipulate it, and some frontend code to support it.