Lightsail CloudFront SSL certificate origin policy issues

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:

Following this guide to a tee creates the 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 and
  • 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:

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

The result of this is it rejects 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 domain as a trusted recipient?

1 Like

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?


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, and 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, is it correct to suggest the origin must have a certificate covering 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.

1 Like

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 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 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

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

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

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 --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: [] 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?

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

Thank you for this, you have solved the problem I was having. That has allowed the SAN certificate to be created inclusive of the 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 domain to work with HTTPS origin policy set.

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