Open n1ngu opened 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
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).
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
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.