feat: Custom Domains UI

[ajhalili2006]

About this Issue

You built a nice webhook backend in Dark for different aspects of your Discord/guilded.gg servers like GitLab CI, Twitch stream notifications and even a bit of deployment statuses from railway.app, and it's your nth canvas to have a custom domain.

The problem? In the current situation, you need to manually contact support every time you want to enable/disable custom domains for your canvases and cross your 🤞 to provision a delightful SSL cert for your custom domain. You want Cloudflare Origin certificates because you placed it behind their proxies? That would be painful if you self-host Dark on your own k8s cluster.

What I Suggest

Maybe implement UI in canvas settings on managing custom domains and handling SSL certs on self-serve basis. By default, we can do a domain ownership verification process through TXT DNS records (like GitLab Pages would do) before issuing a Let's Encrypt cert. In case the system detected that it is behind Cloudflare proxy, either prompt them to disable it OR generate origin certs and add it to the system.

[pbiggar]

I agree, we should have a self-serve for custom domains. Here's a quick design:

The goal is to replace scripts/custom-domains with something implemented in Dark (which can then be improved with notifications, alerts, etc).

These are the parts of custom-domains and their intended replacements:

• get-canvas: we need to get the target domain via DNS. There's probably a .NET library for this, which we could expose via LibDarkInternal.
• _add-to-db: add a LibDarkInternal function that does the same thing
• _add-to-cert-manager, _check-cert-added, check-consistency: create a new service that sits inside the firewall, that listens to a pubsub queue, then does the cert-manager adding/checking. This service would not be exposed to the world, not even internally to bwd-server. A success/failure notice could be sent back via a queue as well. It should take a lock around the kubectl patch because that's racey.

We also need a UI for this: the UI would only be a single text box for the domain, as the rest of it all happens behind the scenes.

Finally, this needs a security review: as it stands, you can point a domain to someone else's canvas and get a HTTPS cert for the domain (which you own and they don't). I believe this is true across all services which use DNS-based verifications, which means I guess it's fine?

[pbiggar]

In case the system detected that it is behind Cloudflare proxy, either prompt them to disable it OR generate origin certs and add it to the system.

Can you discuss this in more detail? I'm not familiar with the origin certs or what they're used for. Can you explain what the goal is?

Thanks again for the report.

[ajhalili2006]

In case the system detected that it is behind Cloudflare proxy, either prompt them to disable it OR generate origin certs and add it to the system.

Can you discuss this in more detail? I'm not familiar with the origin certs or what they're used for. Can you explain what the goal is?

Thanks again for the report.

When requests are being proxied behind Cloudflare servers, the origin certificates serve as a way to protect traffic from Cloudflare to the origin server. This can be a normal CA¹ or the Cloudflare-issued certs. When installed, I can safely dial up the SSL mode to Strict², among other benefits such as speed and simplicity of revocation and ease of issuance and renewal.³

The thing this resolves is the pain of browser-based revocation checking is broken and useless without hard fails and managing multiple certs from different CA.

Footnotes

1. While we can pull a Let's Encrypt certificate, I need to disable SSL for /.well-known/acme-challenge/* via Page Rules. ↩

2. SSL modes only apply to supported DNS records proxied under Cloudflare's network and zones must be unpasued, otherwise expect certificate warnings. ↩

3. Original release blog post: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/ ↩

[ajhalili2006]

I agree, we should have a self-serve for custom domains. Here's a quick design:

The goal is to replace scripts/custom-domains with something implemented in Dark (which can then be improved with notifications, alerts, etc).

These are the parts of custom-domains and their intended replacements:

• get-canvas: we need to get the target domain via DNS. There's probably a .NET library for this, which we could expose via LibDarkInternal.
• _add-to-db: add a LibDarkInternal function that does the same thing
• _add-to-cert-manager, _check-cert-added, check-consistency: create a new service that sits inside the firewall, that listens to a pubsub queue, then does the cert-manager adding/checking. This service would not be exposed to the world, not even internally to bwd-server. A success/failure notice could be sent back via a queue as well. It should take a lock around the kubectl patch because that's racey.

We also need a UI for this: the UI would only be a single text box for the domain, as the rest of it all happens behind the scenes.

Finally, this needs a security review: as it stands, you can point a domain to someone else's canvas and get a HTTPS cert for the domain (which you own and they don't). I believe this is true across all services which use DNS-based verifications, which means I guess it's fine?

Maybe we should do an TXT-based DNS validation first before we handle the Let's Encrypt SSL generation, like what GitLab Pages do on custom domains?

[pbiggar]

Maybe we should do an TXT-based DNS validation first before we handle the Let's Encrypt SSL generation, like what GitLab Pages do on custom domains?

We already do Let's Encrypt-based SSL generation, see services/certmanager and scripts/custom-domains.

[StachuDotNet]

I'm folding this Issue into a larger one shortly - we will eventually have self-serve custom domain UI/UX, but need to reconsider how this should work given recent "darklang-next" work