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?
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?
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.
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.
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.
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.
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).
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:
Revoking the BNCert issued certificate for your domain.
Then, follow this guide (https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach ) for installation of certificates with Lego, with only one exception, when you issue this command " sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" " run, don't use --tls, use --http instead.
