New local dev domain + valid HTTPS cert

[lmakarov]

Add support for *.x.docksal.io with a valid cert from LetsEncrypt.

This will be optional and in addition to the default *.docksal domain.

This requires changes to docksal-vhost-proxy and docksal-dns services.

Related: #1215

[frederickjh]

If it is also possible can we structure the code so that if DOCKSAL_DNS_DOMAIN is set it is also possible to create a LetsEncrypt certificate. My use case for this is, I use Docksal on a development server that uses a domain name that is publicly accessible to allow clients to preview sites.

[lmakarov]

@frederickjh are you asking for a fully automated integration with LetsEncrypt? E.g. just set DOCKSAL_DNS_DOMAIN and have Docksal automatically request certs from LetEncrypt and configure everything?

Something like that would be a killer feature, indeed. However, it will also require a substantial amount of work. For wildcard domains/certs that may not even be possible to fully automate, since LetsEncrypt requires DNS level verification to issue those.

What will be possible - is do the cert request manually and then have docksal-vhost-proxy use it. LetsEncrypt certs are valid for 90 days. After that you'll have to go through the same process again.

[frederickjh]

The manual renewal is OK for me.
Cpanel and Webmin have ways that you can have LetsEncrypt certificates renewed on a timed basis say every 60 days. They also email when they renew or fail to do so.

[lmakarov]

Apparently, the idea of shipping a cert with the app, which points to a local/internal IP is not new.
Also, apparently, this is considered bad and the certificate authority is supposed to revoke such certs.

https://letsencrypt.org/docs/certificates-for-localhost/

This is considered a compromise of your private key, and your Certificate Authority (CA) is required to revoke your certificate if they become aware of it. Many native apps have had their certificates revoked for shipping their private key.

From https://groups.google.com/d/msg/mozilla.dev.security.policy/pk039T_wPrI/nl6jDeEFCgAJ

These certs started being used because Chrome would not allow WSS
connections on non-https.

Long discussion on Reddit on Blizard installing a self-signed cert as trusted on user mahcines:
https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/hey_blizzard_whats_the_deal_with_this_sneaky_root/
This looks to be the only "valid" approach to getting a "valid" trusted certificate for a local domain.

An here's an total overkill option (for local development needs) from Cloudflare: Keyless SSL: The Nitty Gritty Technical Details

[lmakarov]

Adding trusted certs from command line:

• macOS

    sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "/private/tmp/certs/certname.cer"
  

• Linux

    sudo mkdir /usr/local/share/ca-certificates/extra
    sudo cp root.cert.pem /usr/local/share/ca-certificates/extra/root.cert.crt
    sudo update-ca-certificates
  

  Extra treatment may be necessary for browsers, as described in the post.

• Windows

    certutil -enterprise -f -v -AddStore "Root" <Cert File path>
  

[wizonesolutions]

ddev uses mkcert to accomplish this. Then they generate certificates for containers when starting them. Perhaps Docksal could go a similar route.

[lmakarov]

Closing in favor of:

• Switch to *.docksal.site for local environments #1215 (new domain for local dev)
• Docs: Local trusted HTTPS certs using mkcert #1370 (locally trusted HTTPS certs via mkcert)