[Bug]: wildcard certificate for *.shuttleapp.rs does not cover base domain shuttleapp.rs

[paulotten]

What happened?

https://shuttleapp.rs/ on Chrome currently yields a certificate error. The certificate appears to be for "*.shuttleapp.rs" which does not include "shuttleapp.rs".

The certificate appears to be from "Let's Encrypt". Its been a while but I think I remember being able to include the base domain when creating a wildcard certificate with "Let's Encrypt".

Version

n/a

Which operating systems are you seeing the problem on?

Windows

Which CPU architectures are you seeing the problem on?

No response

Relevant log output

No response

Duplicate declaration

• [X] I have searched the issues and there are none like this.

[paulotten]

Chrome

Firefox appears to get the same error (check the network monitor) then on its own initiative redirect to https://www.shuttleapp.rs/.

[iulianbarbu]

Hey @paulotten ! Thanks for reporting this.

Will bring some context on this (cc @chesedo ):

Back in the day as far as I understood we were serving certificates for *.shuttleapp.rs and shuttleapp.rs through AWS Certificate Manager and this was done by using an ALB which intercepted HTTPS traffic and forwarded the requests to an EC2 target group (where we were able to route to the right user project).

This changed though when shuttle-gateway came to life, which took the responsibility of responding to TLS requests only for *.shuttleapp.rs domains and custom domains. My understanding is that we'll have to adjust the gateway certificate to account for shuttleapp.rs as well. I think this is not a straightforward fix but I'll provide here some breadcrumbs:

1. This is the code path to request a Lets Encrypt certificate for *.shuttleapp.rs if it doesn't exist: 1 -> 2 -> 3 -> 4 and then a DNS-01 challenge (given this is a wildcard domain) is sent to our AWS Route53 DNS server which at this time is processed manually with a deadline to be completed in 60 seconds since the challenge starts.

2. Per this post's Wildcard certificates paragraph we'll just need to create an acme v2 Order that's resolving challenges for two authorizations (*.shuttleapp.rs and shuttleapp.rs).

Orders that contain both a base domain and its wildcard equivalent (e.g. *.example.com and example.com) are valid. In that case, there will be two authorization objects in the order for “[example.com 520](http://example.com/)”, one of which represents the wildcard validation and one of which represents the base domain validation. Redundant entries will produce an error. For instance, and order containing both *.example.com and www.example.com would produce an error since the wildcard entry makes the latter redundant.

3. Given we'll be requesting a certificate for shuttleapp.rs (a non-wildcard domain) we can resolve a HTTP-01 ACME challenge by relying on our Bouncer (which already solves http_01 challenges for regular shuttle projects). This is because shuttleapp.rs is still considered a subdomain of *.shuttleapp.rs, given we're checking it by this call.

4. We must test that we'll serve a correct certificate for requests to both wildcard domain (e.g *.shuttleapp.rs) and the base subdomain (shuttleapp.rs). I think this guide might be helpful to test it out locally: https://github.com/shuttle-hq/shuttle/blob/main/admin/README.md.

[paulotten]

Hey @iulianbarbu I think I've got the code written for this. https://github.com/shuttle-hq/shuttle/pull/968

I'm having issues testing it though. I'm trying to follow the steps from https://github.com/shuttle-hq/shuttle/blob/main/admin/README.md#how-to-test-custom-domain-certificates-locally

I'm getting an error trying to run cargo run -p shuttle-admin -- --api-url http://localhost:8001 acme create-account --acme-server https://pebble:14000/dir --email EMAIL_REDACTED

$ cargo run -p shuttle-admin -- --api-url http://localhost:8001 acme create-account --acme-server https://pebble:14000/dir --email EMAIL_REDACTED
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/shuttle-admin --api-url 'http://localhost:8001' acme create-account --acme-server 'https://pebble:14000/dir' --email 'EMAIL_REDACTED'`
thread 'main' panicked at 'to create ACME account: failed to extract json body from post response

Caused by:
    404 Not Found
    message: we don't serve this resource', admin/src/main.rs:31:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Running this locally works:

$ curl http://localhost:8001
{"status":"healthy"}

As does running this from inside the gateway container.

$ docker exec -it ba94487b77d8 bash
root@ba94487b77d8:/# curl https://pebble:14000/dir
{
   "keyChange": "https://pebble:14000/rollover-account-key",
   "meta": {
      "externalAccountRequired": false,
      "termsOfService": "data:text/plain,Do%20what%20thou%20wilt"
   },
   "newAccount": "https://pebble:14000/sign-me-up",
   "newNonce": "https://pebble:14000/nonce-plz",
   "newOrder": "https://pebble:14000/order-plz",
   "revokeCert": "https://pebble:14000/revoke-cert"
}

Any suggestions?

[iulianbarbu]

Hey @paulotten ! Have you created an admin user and logged in before, per the CONTRIBUTING.md guide?

docker compose --file docker-compose.rendered.yml --project-name shuttle-dev exec auth /usr/local/bin/service --state=/var/lib/shuttle-auth init --name admin --key dh9z58jttoes3qvt

cargo run --bin cargo-shuttle -- login --api-key "dh9z58jttoes3qvt"

[paulotten]

@iulianbarbu yes.

Longer answer: I hadn't done it since last remaking the images. Running the docker command now however I get a "UNIQUE constraint failed" error, so the container still has the admin user saved. Checking ~/.config/shuttle/config.toml I see the api key listed above. So I think I'm already good on this step.