0

We're using an ACM certificate to afford custom CNAMEs in a CloudFront Distribution and an API Gateway API. This was working correctly until we recently moved the creation and assignment of this certificate away from a manual process, into an automated one through CI/CD (serverless + CloudFront). The automated process still performs DNS verification via CloudFront's automated Route 53 verification.

Now when accessing either of these resource (ie. the website, as well as the API that the website uses), you get a net::ERR_CERT_AUTHORITY_INVALID.

Note that when I check the certificate from ACM console, it appears everything is correct (says 'Issued' and 'Success'). Also when I inspect the certificate from the browser, it shows Amazon as the correct root authority.

Am I missing something w.r.t. how Root/Subordinate certificates verify the End-entity certificate?

I've been staring at this for like 3 hours and am completely stumped as to what might be going on...

jmkmay
  • 211
  • 2
  • 7
  • What's the actual URL that throws this error? – MLu Jan 10 '21 at 22:09
  • @MLu in the interest of protecting client, I won't reveal the actual domain, but the URL follows: `https://admin.dev/qa/prod.domain.com`. The certificate is valid for `*.dev/qa/prod.domain.com` – jmkmay Jan 10 '21 at 22:28
  • Without knowing the actual name we can’t really help. Try a tool like https://www.ssllabs.com/ssltest/ to see what errors it picks up. – MLu Jan 10 '21 at 22:42
  • Thanks for the tip. It got an A rating... leads me to believe that the Certificate is actually okay, but rather it may have something to do with the way its setup/referenced in CloudFront and API Gateway. – jmkmay Jan 10 '21 at 23:34
  • It could be the client setup too. Try from a completely different laptop and browser, or from your smartphone. – MLu Jan 10 '21 at 23:36
  • Now I'm getting NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED all of a sudden.... ZZZZZZZ – jmkmay Jan 10 '21 at 23:36

0 Answers0