calidae / terraform-aws-bitbucket-oidc

Create a Bitbucket OpenID Connect provider and aid you to write json policies to assume roles

MIT License

1 stars 1 forks source link

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

Open n1ngu opened 2 years ago

n1ngu commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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