Lightsail CloudFront SSL certificate origin policy issues

Help
#1

Hey everybody,

Thanks for taking the time to read this help request.

I have a Lightsail instance with its own SSL certificate generated using the BNCert tool. This all works fine and https works correctly.

When following this guide by the AWS team to enable CloudFront distribution, issues start to happen: https://aws.amazon.com/blogs/compute/improving-website-performance-with-lightsail-content-delivery-network/

Following this guide to a tee creates the xxx.cloudfront.net distribution, which interacts with the Lightsail installation with a HTTP origin policy.

When switching the origin policy to HTTPS, a 502 error presents itself.

After troubleshooting, I've determined the following:

  • The Lightsail installation works fine and the certificates generated by the BNCert tool cover www.domain.com and domain.com
  • Using the Lightsail CloudFront distribution over HTTP as the origin policy also works because no HTTPS request is being made.
  • When setting the origin policy to be HTTPS only on the Lightsail side results in the following error:

Screen Shot 2020-10-02 at 6.53.38 pm
Screen Shot 2020-10-02 at 6.53.38 pm2474×506 77.8 KB

My understanding of the issue is that the certificate generated by Lightsail, which covers the xxx.cloudfront.net distribution, along with www.domain.com and domain.com is adequate for the distribution side. But, the certificate on the Lightsail side only covers www.domain.com and domain.com.

The result of this is it rejects xxx.cloudfront.net because it's not specified as a domain on the Lightsail end (where the SSL certificates were generated by BNCert tool).

So my question is – is it possible to allow the SSL certificate on the Lightsail side to include the xxx.cloudfront.net domain as a trusted recipient?

1 Like
#2

I don't think that's what you would want to do.

According to Cloudfront docs:

The certificate returned from the origin must cover the domain that you specified for Origin Domain Name for the corresponding origin in your distribution. In addition, if you configured CloudFront to forward the Host header to your origin, the origin must respond with a certificate matching the domain in the Host header.

Did you give your Cloudfront distribution an Origin Domain Name which matches your origin certificate?

3 Likes
#3

Hey @_az,

Thanks for taking the time to reply.

Yes, I did that. Within the Custom Domain settings for Lightsail there is an ability to create certificates for the domain being serviced by the Cloudfront instance.

I created a certificate for two domains, domain.com and www.domain.com. I have included screen shots below. You can also see where these certificates are marked as valid and in use. The domain certificates are verified through the use of CNAME entries in the DNS.

If my understanding of the section of the documentation you have pasted there is correct, when the host header is forwarded from xxx.cloudfront.net, is it correct to suggest the origin must have a certificate covering xxx.cloudfront.net as well? Or am I reading that wrong?

I have redacted the section with the domain name – this is simply because it's the domain name for a school football team.

Thanks again for your assistance.

Screen Shot 2020-10-06 at 8.14.58 pm
Screen Shot 2020-10-06 at 8.14.58 pm1448×1494 251 KB

1 Like
#4

I played around a bit more and I think you're right.

On my own Cloudfront distributions, I have them setup to not forward the Host header, which I believe is the default mode.

So that means I can access my distributions using the cloudfront.net domain or the alternate domains, with the HTTPS-only Origin Policy, and it works both ways.

If, on the other hand, you do have Host forwarding enabled, then I guess your initial conclusion is correct:

I tried this out, and it does work. Amazon only block wildcard certificates (via CAA record), but regular xyz.cloudfront.net certificates can be issued by e.g. bncert just like any other domain.

I don't know if Bitnami's bncert tool supports adding arbitrary additional SANs to your certificates - that's probably a question for the Bitnami community. Even if it doesn't, you could probably just follow the lego-based instructions instead, which do allow for that.

1 Like
#5

Thank you for that reply.

I just tried removing the host header forward and setting the HTTPS origin and it came up with the same 502 error.

But, I think you're right about the SAN certificates. When using the BNCert tool, it does a DNS check to ensure the TLD is pointing to your IP. This fails with CloudFront because it doesn't point to the same IP as the distribution.

Let me check with the Bitnami guys whether there's a method of ignoring the DNS check and finally, I'll check by making another certificate through Lego to see if that works.

Thanks again and I'll report back with a solution just in case anybody else runs into this issue.

1 Like
#6

Weird. Cloudfront distributions can take like 20+ minutes to fully propagate changes, was it still not working after waiting for the status to update?

Good luck anyhow.

1 Like
#7

I discussed this with the Bitnami guys and they said BNCert Tool can't avoid the DNS lookup and they suggested trying Lego directly.

So I've tried Lego with the following command:
sudo /opt/bitnami/letsencrypt/lego --tls --email=myemail@gmail.com --domains=mydomain.com --domains=www.mydomain.com --domains=xxx.cloudfront.net --path=/opt/bitnami/letsencrypt run

And it's coming up with the following error:

Could not obtain certificates: error: one or more domains had a problem: [xxx.cloudfront.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Cannot negotiate ALPN protocol acme-tls/1 for tls-alpn-01 challenge, url:

You mentioned earlier that Lego allows for SANs outside of the DNS to be registered, but I'm not sure I see the way to make this happen. This command still performs a DNS challenge of some sort to confirm the URL is hosted on the same IP as the server.

Is there something I'm missing with the command?

#8

You can't use the TLS-ALPN challenge with Cloudfront, because it works by negotiating some stuff during the TLS handshake, but Cloudfront terminates its own TLS (rather than proxying the handshake to you).

It's no big deal though, just use the HTTP challenge instead.

I'm not a lego user but, I reckon all you need to do is replace --tls with --http.

(And of course, your webserver shouldn't be running. if you wanna keep it running, you'll have to work out how to use the webroot solver in Lego).

1 Like
#9

Thank you for this, you have solved the problem I was having. That has allowed the SAN certificate to be created inclusive of the xxx.cloudfront.net domain mentioned.

For anybody else facing the same issue, you can solve this by:

It took a while, but thankfully that has solved the issue and now allows the xxx.cloudfront.net domain to work with HTTPS origin policy set.

Thanks to @_az for spending so much time to assist with this, it's greatly appreciated.