configure-aws-credentials: Error: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint

Describe the bug

My github workflows that use aws-actions/configure-aws-credentials@v1-node16 have stopped working today. No changes have been made recently to the workflows, or my AWS accounts.

Expected Behavior

The step should succeed without any error.

Current Behavior

Error logged in the GitHub runner

Run aws-actions/configure-aws-credentials@v1-node16
  with:
    role-to-assume: arn:aws:iam::xxxxxxxxxxx:role/github-actions-role
    aws-region: eu-west-2
    audience: sts.amazonaws.com
Error: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint

Reproduction Steps

I’ve copied what I think are the relevant parts of my workflow yml.

name: Test Workflow
on: push
permissions:
  id-token: write
  contents: read
env:
  aws_tools_account: "00000000000"
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: "Configure AWS Credentials: Tools account"
        uses: aws-actions/configure-aws-credentials@v1-node16
        with:
          role-to-assume: arn:aws:iam::${{ env.aws_tools_account }}:role/github-actions-role
          aws-region: eu-west-2

Possible Solution

No response

Additional Information/Context

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 5
  • Comments: 16 (1 by maintainers)

Most upvoted comments

I had a same issue, but solved it by adding the latest fingerprint from this one-liner to ID provider. https://github.com/aws-actions/configure-aws-credentials/issues/357#issuecomment-1183591299

Yeah I think that is certificate’s thumbprint. If you try creating IdP frm IAM console it uses ICA’s thumbprint image

The thumbprint of the certificate will vary with each rotation, but the not the ICA’s(This is also not guaranteed but generally ppl use same ICA for certian period). FYI : Here is the last time’s blog post https://github.blog/changelog/2022-01-13-github-actions-update-on-oidc-based-deployments-to-aws which mentions using 6938fd4d98bab03faadb97b34396831e3780aea1 as the thumbprint

Using the 6938 Thumprint fixed it for us. We must have been using an old certificate (not ICA), which we probably got from a similar one-liner that is giving the f879 number now. So I’d expect that to work again too, but break again later. Be careful out there!