Unable to use AWS Cloudfront as proxy to serve RTD project at custom domain via https

[ryanpitts]

I'm trying to use AWS Cloudfront as a proxy to securely serve this RTD project at a custom domain.

It feels like it should work, and in fact it almost works. Currently the custom domain forces all traffic to https, but then forwards to the secure readthedocs.io project domain instead of serving at the custom domain.

• Custom domain: https://securitytraining.opennews.org/
• RTD public-facing domain: https://the-field-guide-to-security-training-in-the-newsroom.readthedocs.io/en/latest/
• RTD project URL: https://readthedocs.org/projects/the-field-guide-to-security-training-in-the-newsroom/

I'm following the documentation here for serving RTD projects at alternate domains. It suggests a handful of custom headers to set. A couple of key things to note:

• My Cloudfront distribution is setting X-RTD-SLUG. This seems most important.
• Cloudfront does not allow forwarding a Host header (along with a handful of other custom headers).

I'm hoping that someone else might have some experience with making Cloudfront work here (or alternatively, can explain why there's no way to make it work if I can't forward Host). Really seems like it's thisclose.

[humitos]

The key thing of that nginx configuration is the proxy_pass: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

With the current configuration, we are getting just a 302 from https://securitytraining.opennews.org/ pointing to the URL in RTD.

[ryanpitts]

thanks @humitos! There's not a direct way to define proxy_pass in the AWS Cloudfront config—I think the analog is setting the origin domain. Here's the relevant part of the Cloudfront distribution config:

It's a bit cut off in the screenshot, but the value of the "Origin Domain Name" field is set to the-field-guide-to-security-training-in-the-newsroom.readthedocs.io

[stsewd]

RTD now supports https on custom domains, let us know if you still need help.

[ryanpitts]

oh fantastic! thank you!

[stsewd]

Here are the docs btw https://docs.readthedocs.io/en/latest/alternate_domains.html#cname-ssl

[ryanpitts]

First of all, thank you so much for building this feature into RTD! I'm not sure if I should reopen this ticket (or probably create a new one), but now that I've followed this documentation and switched our project to use https on a custom domain as described, I'm noticing that:

• This works great: https://securitytraining.opennews.org
• But this does not automatically redirect to https: http://securitytraining.opennews.org

I've checkmarked "Always use HTTPS for this domain" in the RTD admin for this project, which sounds like it would enable automatic forwarding. Is it possible this is a bug, or is this expected behavior and I'm misunderstanding here?

[stsewd]

@ryanpitts I think this is the same problem as #4395 (comment)

[davidfischer]

As @stsewd suggested, we are working toward implementing redirects. They are a bit harder as most documentation is served without actually hitting our app/database layer but we need to hit that layer to tell whether we have successfully provisioned the certificate and that the "always use HTTPS" checkbox is selected. I'm actively working toward this so stay tuned.

[ryanpitts]

Awesome! Thanks so much for the update. And for working on https for custom domains overall. Super helpful and appreciated.

[agjohnson]

Opened #4641 to track changes to always redirect to HTTPS/enable HSTS