InvalidIdentityToken: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint

[n1ngu]

After Atlassian rotated their HTTPS certificate on 24th June 2022, the AWS OIDC provider stopped working.

See https://bitbucket.status.atlassian.com/incidents/3s2tb3329ftd

The certificates that are fingerprinted by the module should be those listed in https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/#api-workspaces-workspace-pipelines-config-identity-oidc-keys-json-get and not the one that is used in the TLS layer of the API, although they were the same leading to this confusion.

[n1ngu]

Given the note

AWS secures communication with some OIDC identity providers (IdPs) through our library of trusted certificate authorities (CAs) instead of using a certificate thumbprint to verify your IdP server certificate. These OIDC IdPs include Google, and those that use an Amazon S3 bucket to host a JSON Web Key Set (JWKS) endpoint. In these cases, your legacy thumbprint remains in your configuration, but is no longer used for validation.

from https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html , it seems that those certs should be used regardless of the thumbprint? Yet, AWS is not acknowledging the .well-known/openid-configuration resource served by Bitbucket API's in https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/#api-workspaces-workspace-pipelines-config-identity-oidc-well-known-openid-configuration-get

[n1ngu]

Previous messages are from an utterly astray person.

Fingerprinted TLS certs have nothing to do with the JWKS listed inside the OIDC provider (.../.well-known/openid-configuration and whatnot).

#2 mitigates this issue but

• a new disruption is still unavoidable before 22th Oct 2028 when DigiCert's current operative intermediate cert will expire
• does not solve the scenario where Atlassian legitmately switches their CA of choice to generate their end TLS certificates
• yet another disruption is unavoidable before 10th Nov 2031 when DigiCert's root certificate will expire, requiring a rotation for all the api.bitbucket.org certificate chain

IMHO, AWS requirement to fingerprint TLS certs just makes no sense when a CA is in place, but there is little one can do around it. See https://stackoverflow.com/questions/72805530/how-to-not-thumbprint-aws-oidc-provider-rotating-certificate