Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

maintenance should serve all domains #7

Open
rgaudin opened this issue Apr 16, 2024 · 2 comments
Open

maintenance should serve all domains #7

rgaudin opened this issue Apr 16, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@rgaudin
Copy link
Member

rgaudin commented Apr 16, 2024

We've seen that users tend to directly access subdomains of the demo which fails in an unexpected way during maintenance as we are not serving those subdomains.

@benoit74
Copy link
Contributor

As discussed, the "main" problem with serving subdomains during maintenance is that:

  1. we do not really know the list of subdomains which are served by an hotspot
  2. we cannot configure that "all subdomains" are returned the maintenance message because it would cause a problem with issuing SSL certificates

The SSL certificates issue is linked to the fact that we use the HTTP challenge, hence needing a list of subdomains to retrieve a certificate for.

While it is possible to configure Caddy to retrieve these certificates at runtime (i.e. once a request is received on a given subdomain), it is risky because it means that anyone could generate hundreds of certificates (by randomly trying many subdomains) and we would be banned from our certificate issuer.

I see two way forward:

  1. hard-code the list of subdomains currently used ; this is probably the simpler solution, but I'm pretty sure we will add a service at some point and forget to update the demo
  2. use DNS challenge instead of HTTP ; this means that we must grant access to Caddy to update our DNS zone

Point 2 while more complex is my preference, since this could be a great opportunity to try using https://desec.io/ and its fine-grained permissions model. We could delegate only a subdomain to desec.io for now (demo.hotspot.kiwix.org is sufficient) and see how it works on a non-critical part of our infrastructure.

@rgaudin
Copy link
Member Author

rgaudin commented Apr 16, 2024

That's why it's a ticket and not a + *: commit 😉.

I also think we should use this as an opportunity for using a DNS Challenge but I'm more skeptical regarding changing DNS Hosting. dnssec.io looks fantastic but it's a free service with no warranty. I don't see us using it for the rest so it looks like an effort that cannot scale. We should discuss it with @kelson42

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants