Invalid or missing intermediate (bundle) certificate.

Is it possible that you might be experiencing the effects of what is described in this blog post?

If ACM issued the certificate, instead of you importing a certificate issued by another party into ACM, the correct certificate chain will be configured automatically when you associate the certificate with your CloudFront distribution. I suggest you check the certificate details in ACM first. Specifically, is the certificate in issued or pending status, is its expiration time in the future, and does ACM show it as being associated with the correct CloudFront distribution?

If all the above checks out, then check with a command line tool like nslookup or dig if the IP addresses returned for the native DNS name of the CloudFront distribution match the IP addresses returned for the DNS name you're trying to use to access your site. This is just to make sure the request is actually being sent to CloudFront and not to any earlier location where DNS might still be pointing.

It sounds like you either imported a certificate you generated or obtained from elsewhere into ACM, rather than ACM generating a certificate for you, or you aren't connecting to your CloudFront distribution but to an intermediate network device. For example, there are corporate environments that use a firewall or proxy server to intercept TLS connections and decrypt them for content inspection on the firewall. In that case, your computer wouldn't see the certificate coming from CloudFront but a fake certificate coming from the corporate firewall or other traffic-intercepting device.

The error message said on October 30th that the server's certificate had expired 94 days ago, on July 28th, and that clearly isn't the certificate from ACM that CloudFront is using with an expiration date in September of 2025.

Are you using your own, personal computer connected to your home internet connection, or is your computer behind a firewall or using some VPN or other corporate networking or tunnelling solution?

The certificate attached to your CloudFront distribution was issued by ACM on June 30th, 2023. The certificate expired 13 months later on July 30th, 2024. The error message the browser shows about the certificate being expired is correct, so the problem is in your CloudFront configuration:

I suggest you open the properties of your CloudFront distribution in the management console. In the middle of the General tab, there should be a link to the "Custom certificate" attached to your distribution. Clicking it will take you to ACM and show the exact certificate that is actually used by CloudFront. I'm sure you'll see on that screen that the Status shows as "Expired" and the dates match my screenshot.

In the ACM console, still in the us-east-1 (N. Virginia) region, click "Request certificate" on the left. Select "Request a public certificate". On the next screen, enter kloudbay.com in the text box, then click "Add another name to the certificate" and enter the wildcard name *.kloudbay.com, which will allow using the www. variant of the name. Choose "DNS validation - recommended" (and not email validation) as the validation method, and change the key algorithm to "ECDSA P 256". Click Request at the bottom of the screen.

When the request has been made, click the "View certificate" button in the notification bar at the top of the screen. It will show the CNAME record you need to validate the certificate request. You can click the "Create records in Route 53" button to create the record automatically, if the Route 53 hosted zone is in the same account, or if the zone is in a different account, you'll have to add the CNAME record the console shows manually.

Capture the 36-character dashed hexadecimal "Identifier" of the certificate before proceeding to the next step.

When the certificate shows the status "Issued", open the CloudFront console and open your distribution. On the General tab, click the Edit button. In the dropdown menu "Custom SSL certificate - optional", choose the new certificate you just created based on its 36-character ID. While you're making the changes anyway, I suggest that from the "Security policy" list, you choose "TLSv1.2_2021 (recommended)". You should also ensure that IPv6 is set to "On". Click Save changes.

Deploying the configuration changes can take a while, often on the order of 10 minutes. The distribution list in the CloudFront console will show "Deploying" as long as the updates are in progress. Once the Status changes from "Deploying" to "Enabled", it's all done.

When you test, you should see that your site is working fine.

Finally, you should add an AAAA alias record for your site in the Route 53 hosted zone and point it to the same CloudFront distribution. This allows the rapidly increasing number of users on IPv6 networks to access your site without their internet operator having to translate their addresses to the legacy IPv4 address space.

In the ACM console, you should also find the old, expired certificate. Open the certificate details and make sure no "associated resources" are shown. Click "Delete" at the top right-hand corner to dispose of the expired certificate that serves no purpose.

It is the same certificate (ending with 505d94) is configured for cloud front distribution(E3JOIUT5B0SNZG), verified that. Following your suggested steps earlier, created this certificate and if you observed the screenshot, the Associated Resources section shows the cloud front distribution ARN (E3JOIUT5B0SNZG). Screenshot of the cloud front distribution settings

Verified the DNS servers, they are configured correctly. And screenshot of A record in Route 53 hosted zone configuration which looks correct.

Also the cloud front distribution details, screenshot below

Thank you again for all your help and suggestions. I’m at a bit of a standstill, so any further guidance would be greatly appreciated.

Screenshot below has the naming servers.

Thank you again for all your help and suggestions.

The screenshots just don't match what is actually online on the internet. kloudbay.com and www.kloudbay.com point to a CloudFront distribution that serves an expired TLS certificate using a 2048-bit RSA certificate and not the new ECDSA certificate that shows as being attached to the CloudFront distribution your screenshots are showing.

The way this could happen is that the DNS name is pointing to a different CloudFront distribution, which has the expired certificate still attached.

I'm not sure if we can make any progress with reality and our discussed troubleshooting steps simply not matching, but you could still do a few things:

1. Open the old, expired certificate in the ACM console and check if it shows any associated resources, particularly CloudFront distributions. If no associated resources are listed, delete the certificate from ACM. This will ensure we won't receive that specific certificate via CF.
2. Get a single screenshot of the Route 53 hosted zone with both the hosted zone details and the alias records for kloudbay.com and www.kloudbay.com in the same screenshot. As usual, redact sensitive details.
3. In the distribution list in the CloudFront console, make sure that the "Type" column shows "Production" and the "Status" as "Enabled" for your CF distribution.
4. Add the name kloudbay.com (without a prefix) to the CF distribution's alternate DNS name list. The current pattern *.kloudbay.com will match www.kloudbay.com but not the plain name kloudbay.com.

If all is still okay, then temporarily, remove all the alternate names from the CloudFront distribution and detach the custom certificate from it. Wait for the distribution to get deployed. Modify the distribution again, attaching the custom certificate and adding the alternate names kloudbay.com and www.kloudbay.com (or *.kloudbay.com if you need other hostnames aside from www.). Wait for the distribution to finish getting deployed, and test if it works. It's unlikely that this is needed, but in the unlikely case that the configuration has gone out of sync somewhere along the way, this should cause the TLS configuration to get redeployed entirely.