Respond with origin certificate for all domains

I am trying to use cloudfront to point to my origin which serves a couple of domain names. Cloudfront provides the end user ssl termination and requests the data from the caddy origin. According to cloudfront docs, it expects all requests to the origin to use an ssl certificate authorized for the origin domain regardless of request host.

The origin fqdn is origin.example.com. The requested domain is www.example.com

Right now, when I am directing cloudfront requests as caddy, the response is “404 Site www.example.com is not served on this interface”.

I had to break my post into two parts. Forum errored with new users cannot post more than 4 links.

I would like to do something like:

origin.example.com, * {
tls {
force-fqdn: origin.example.com
}
proxy / http://proxy {
transparent
}
}

I don’t know if Caddy can accommodate this with Automatic HTTPS.

We use the request host very early on in the request handling process to narrow down which configuration to use, and present the appropriate certificate at connection. Marking out the site definition as a default vhost doesn’t affect that, I’m afraid.

You can get your own certificate for origin.example.com and then specify it with tls cert key, using the catch-all site label - it just won’t work with Automatic HTTPS (so you’ll have to specify ports).

1 Like

Hrm… is it possible to setup the “origin.example.com” block to automatically request the certificate and then set up a separate wildcard block that would always return this certificate? I know the “origin.example.com” domain name in advance. Is there a way to reference the certificate that will be fetched to disk later?

I.e.

origin.example.com {
proxy / http://proxy {
transparent
}
}

(edit format fix) * {
proxy / http://proxy {
transparent
}
tls {
path: where origin.example.com cert will eventually exist
}
}

Yes, you can do this.

The first time you launch it, you might have to comment out the catch-all until the certificate is acquired - I think you’ll run into an error that it couldn’t read the certificate if it hasn’t been retrieved yet.

The location of the certificate will be fixed; you can navigate the CADDYPATH until you find it and copy the path to it, which will remain the same over time (at least until LetsEncrypt move to a hypothetical v3 API at some future date).

Hrm I was hoping for something a little less hacky feeling. Any chance something like this would be accepted as an issue on GitHub?

You can absolutely open an issue where some of our contributors can potentially weigh in on it; you can argue your use case (Cloudfront) is worth explicitly supporting.

Strictly speaking, Caddy does support the configuration you require - it just doesn’t mesh with Automatic HTTPS, which is a feature that makes a lot of assumptions to provide a secure-by-default website. I don’t think it’s likely Automatic HTTPS will be changed to accommodate this if we have to change or make new assumptions on behalf of the end user to do it; we already see occasional confusion despite the straightforward documentation.

Hey whitestrake,

I don’t think this is cloudfront specific or anything. Just a cdn or front end reverse proxy that will accept a certificate for the origin server address to serve multiple domains?

The benefit is that the caddy proxied service doesn’t have to use tls on demand and implement an ask endpoint

I haven’t read the code and I’m not fluent in go, but I figured this would be something along the lines of the tls configuration that serves a cert path but since it doesn’t exist until caddy fetches it is a lazy operation

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.