SPIKE: Update HTTPS certificate to support *.*.altis.dev

[roborourke]

SPIKE: Update HTTPS certificate to support *.*.altis.dev

[mikeselander]

I'm also now running against this on a separate client from Than. Both of his requests would be exceedingly helpful if we can't setup the certificates correctly automatically.

[rmccue]

Caddy's is powered by smallstep under the hood; related Chassis discussion: Chassis/chassis_openssl#15 (comment)

[jennybeaumont]

It was determined that this isn't technically possible.

[rmccue]

mkcert is not really programmatically usable, that's part of the reason I hadn't dug into it further for Chassis. And Smallstep is what's used inside Caddy I believe.

[roborourke]

Marking this as future release because it's literally impossible with a single certificate. This would require significant amount of work to change to either generating self signed certs and adding those programmatically to a trusted store as per local-chassis or building out some sort of service that updates the altis.dev DNS records on demand for provisioning certs with LetsEncrypt.

[goldenapples]

I'm running up against this right now, and would love to see one of the following:

• instructions for generating a self-signed certificate and configuring it to be used within altis-local-server-nginx.
• the ability to run local-server with HSTS disabled.

[nathanielks]

I don't have time to read this now, but i want to leave this for my future self: https://www.smarthomebeginner.com/traefik-2-docker-tutorial/

[nathanielks]

Also making note that Caddy 2 might be a good replacement as it can manage/generate TLS certificates: https://caddyserver.com/v2

[nathanielks]

TL;DR: they generate their own trusted CA locally: https://caddyserver.com/docs/automatic-https#local-https

[jennybeaumont]

Closing in favor of #151

[roborourke]

For anyone googling this - a short term workaround if you're using Google Chrome is to type thisisunsafe on the HTTPS warning screen you get when navigating to a sub-sub domain of altis.dev

[nathanielks]

Without context, I don't see #151 solving this issue. Is there more context that can be added?

[nathanielks]

FWIW I do think this is technically possible. When spinning up local-server, we know what the second star is in the url (*.<project name>.altis.dev). Now it's a matter of enabling SSL certificate creation when the project is started up creating a wildcard certificate for *.<project name>.altis.dev.

[roborourke]

#151 hints at being able to choose the URL local server runs on, i.e. moving away from the altis.dev requirement. Maybe technically possible but very difficult and not something there's really been a strong will for anyone to dive into so far. If we can make SSL work *.<project>.altis.dev then presumably we can use that same solution for providing SSL for any desired local URL.

[nathanielks]

TL;DR: I've done some messing around this evening and this definitely appears possible with Traefik v2 and tools like mkcert. Traefik v2 allows for dynamic configuration updates, meaning the proxy can be running and dynamically add new SSL certificates. Upgrading to Traefik v2 changes a good bit of how are configured, but I'd say it's within the realm of feasability, though requiring more than the 2 hours or so I've put looking into it 🙂

[nathanielks]

The other TL;DR is composer local-server up would create SSL certificates if they don't exist, place them in a folder Traefik has mounted as a volume, and manage a file Traefik would read for configuring itself with the SSL certificates.

[jennybeaumont]

Shall we reopen? Does this deliver value? Do we have a clear path forward?

[roborourke]

I think we more or less ruled out mkcert as it can’t be bundled with this package neatly. @rmccue mentioned using Caddy but I’ve not really managed to grok how to use it yet.

There is value in this I just thought we’d take a different approach. I’ll reopen.

[nathanielks]

I had similar issues with Caddy. I started with that first last night. It worked great for anything localhost/127.0.0.1, but DNS addresses it attempts to use Let's Encrypt to generate a certificate (even if the address resolves to localhost).

For mkcert, we could wrap the CLI like we do docker-compose, I reckon. I'm not dedicated to mkcert, either. I'm curious about Smallstep's tool, too, but didn't mess around with it at all.

[nathanielks]

All that to say, whenever this gets reprioritized, a spike to play around with what options we have available would be good 😀

[joehoyle]

Not sure if it's mentioned here, but it's not possible to use self-signed certs on *.dev domains. It's also not possible to get a cert signed for *.*.altis.dev as far as I know (SSLMate were not able to, and said it's not supported by the spec)

[sivanovhm]

Based on RFC6125, my understanding is that only a single level of wildcard domain can be used. (I am assuming the same would be valid for self-signed certs as well).

In other words, if dev names are structured <projectname>.altis.dev, the correct way to proceed is to have one certificate for every project which contains both *.<projectname>.altis.dev and <projectname>.altis.dev.

That said, *.*.altis.dev should not work. Even if we manage to issue them, I don't think clients (browsers, curl, etc) would consider them as valid.

I'm totally unaware of how everything is packaged, yet, but from the tip of my head came the following idea:
certbot docker image + configured hook to a script to automatically add the needed records for validation. I haven't used it before but It looks like a possible approach. That is if I am not totally out of context due to missing knowledge regarding our platform. An example of what I described can be found here

[roborourke]

@sivanovhm youre quite right it’s not possible. Certbot has been tricky to get working in my early efforts so I’m thinking that commands to wrap the mkcert program is the way to go

[roborourke]

Regarding .altis.dev we ship a cert with local server and have the DNS for *.altis.dev pointing to localhost