Our Acme-chief system for provisioning Let's Encrypt certs has support for http-01 challenges. The ::profile::acme_chief class includes comments describing how to configure an nginx service to forward /.well-known/acme-challenge/... URLs to acme-chief for validation.

Supporting apex domains (like example.com) may be fragile because of DNS limitations on CNAME usage. For subdomains (like my-tool.example.com or www.example.com) it should be sufficient to create a CNAME record in the external DNS provider's system that points the subdomain at our wmcloud.org host.

I don't think that providing DNS services or domain parking should be considered in-scope for this feature.

Right now the Cloud VPS system makes a fairly heavy assumption that everything it handles has its DNS hosted on our Designate servers, and changing that is a somewhat large project.

A relatively simple solution would be to set up a new VM or two with the profile::wmcs::proxy::static profile (which was originally invented for the maps proxy), point a new (single) floating IP to that server and tell everyone using this system to ask us to manually update the mappings when they need those to be changed.

Change 1010505 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] dynamicproxy: add support for per-project zones

https://gerrit.wikimedia.org/r/1010505

Change 1010506 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] dynamicproxy: allow specifying different certs for each zone

https://gerrit.wikimedia.org/r/1010506

Change 1010505 merged by Majavah:

[operations/puppet@production] dynamicproxy: add support for per-project zones

https://gerrit.wikimedia.org/r/1010505

Change 1010506 merged by Majavah:

[operations/puppet@production] dynamicproxy: allow specifying different certs for each zone

https://gerrit.wikimedia.org/r/1010506

The patches merged above add support for adding zones that are not visible to all projects, and configuring an individual zone to use a specific TLS certificate. I believe the next steps are, roughly, to:

• Add support for zones that are not managed in Designate. This includes setting up the proxy to route http01 ACME challenges to the acme-chief host.
• Add support for configuring proxies in the zone apex.
• Figure out and document a process for enabling this on a project.

Change 1011167 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] P:acme_chief: allow enabling http-01 spport

https://gerrit.wikimedia.org/r/1011167

Change 1011168 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] P:wmcs::novaproxy: proxy http-01 challenges to acme-chief

https://gerrit.wikimedia.org/r/1011168

Change #1011167 merged by Majavah:

[operations/puppet@production] P:acme_chief: allow enabling http-01 spport

https://gerrit.wikimedia.org/r/1011167

Change #1011168 merged by Majavah:

[operations/puppet@production] P:wmcs::novaproxy: proxy http-01 challenges to acme-chief

https://gerrit.wikimedia.org/r/1011168

Change #1083858 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] P:wmcs::novaproxy: Fix nginx config order

https://gerrit.wikimedia.org/r/1083858

Change #1083858 merged by Majavah:

[operations/puppet@production] P:wmcs::novaproxy: Fix nginx config order

https://gerrit.wikimedia.org/r/1083858

Change #1083862 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] dynamicproxy: Allow creating proxy at zone apex

https://gerrit.wikimedia.org/r/1083862

Change #1083868 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] dynamicproxy: Allow zones not managed in Designate

https://gerrit.wikimedia.org/r/1083868

Note to self: we might want to add CAA records for any aliases that people will point CNAMEs to, to prevent people like me who have those configured from having cert issuance being rejected by that.

Change #1084172 had a related patch set uploaded (by Majavah; author: Majavah):

[openstack/horizon/wmf-proxy-dashboard@main] Allow creating apex domains

https://gerrit.wikimedia.org/r/1084172

Change #1083862 merged by Majavah:

[operations/puppet@production] dynamicproxy: Allow creating proxy at zone apex

https://gerrit.wikimedia.org/r/1083862

Change #1083868 merged by Majavah:

[operations/puppet@production] dynamicproxy: Allow zones not managed in Designate

https://gerrit.wikimedia.org/r/1083868

Change #1084172 merged by Majavah:

[openstack/horizon/wmf-proxy-dashboard@main] Allow creating apex domains

https://gerrit.wikimedia.org/r/1084172

https://lists.wikimedia.org/hyperkitty/list/cloud-admin@lists.wikimedia.org/thread/XHUP2ERZ2W6LHILNXZOPHC37ITDBZYW6/#XHUP2ERZ2W6LHILNXZOPHC37ITDBZYW6

I wonder if T376637: Enable use of web proxy for wikiwho.net domain could be one? Though they seem to want a redirect more than a real vanity url.

In T342398#10285184, @taavi wrote:

Next up I think is to find a real project with real traffic that wants to give this a try.

We're curious about this for The-Wikipedia-Library. One problem we have with it is that it's a hard URL to remember (https://wikipedialibrary.wmflabs.org/) - would this make it possible for us to do something like library.wikimedia.org, wikipedia.library.org, or wikipedialibrary.org? I'm not specifically attached to any of those, just trying to understand what the options are :)

In T342398#10292421, @Samwalton9-WMF wrote:

In T342398#10285184, @taavi wrote:

Next up I think is to find a real project with real traffic that wants to give this a try.

We're curious about this for The-Wikipedia-Library. One problem we have with it is that it's a hard URL to remember (https://wikipedialibrary.wmflabs.org/) - would this make it possible for us to do something like library.wikimedia.org, wikipedia.library.org, or wikipedialibrary.org? I'm not specifically attached to any of those, just trying to understand what the options are :)

This is a 'bring your own domain' type feature - you would need to acquire and manage the (sub)domain on your own, with the Cloud VPS infrastructure only managing the parts required for the web proxy to work (unlike *.wmcloud.org where we handle everything).