AWS China OIDC / IRSA Troubleshooting Guide

Error: InvalidIdentityToken: No OpenIDConnect provider found in your account for https://<your-spacelift-hostname>

If you have confirmed the OIDC provider exists in your AWS China account, the error message can still be misleading. Here are the next likely culprits:

1. URL Exact Match Mismatch

AWS performs a strict string comparison between the issuer in the JWT token and the registered OIDC provider URL. Even a trailing slash difference will cause this error.

Verify the registered URL exactly:

bash

aws iam list-open-id-connect-providers \  --endpoint-url https://iam.cn-north-1.amazonaws.com.cn
aws iam get-open-id-connect-provider \  --open-id-connect-provider-arn arn:aws-cn:iam::<account-id>:oidc-provider/<your-spacelift-hostname> \  --endpoint-url https://iam.cn-north-1.amazonaws.com.cn

Compare the Url field returned against your Spacelift hostname — no trailing slash, exact casing.

2. STS Regional Endpoint Not Configured

AWS China does not have a global STS endpoint. If the Terraform AWS provider is not explicitly pointed at a China STS endpoint, AssumeRoleWithWebIdentity calls may fail or hit the wrong partition entirely.

Ensure your China provider block explicitly sets the STS endpoint:

hcl

provider "aws" {  region = "cn-north-1"  # or cn-northwest-1  endpoints {    sts = "https://sts.cn-north-1.amazonaws.com.cn"  }}

3. Thumbprint Mismatch

Certificates rotate. If the registered thumbprint no longer matches the current TLS certificate on the OIDC endpoint, tokens will be rejected.

What is the thumbprint?

The thumbprint is the SHA-1 fingerprint of the root CA certificate at the top of the TLS chain — not the leaf/server cert:

Root CA Certificate          ← thumbprint comes from HERE
    └── Intermediate CA
            └── Leaf/Server Certificate  ← what your browser sees

Verify the current thumbprint

bash

# Extract all certs in the chainopenssl s_client -connect <your-spacelift-hostname>:443 \  -showcerts </dev/null 2>/dev/null \  | awk '/BEGIN CERT/,/END CERT/{ print }' \  | awk 'BEGIN{n=0} /BEGIN CERT/{n++} {print > "cert" n ".pem"}'# Fingerprint each cert and compare against what is registered in IAMfor i in cert*.pem; do  echo "$i:"  openssl x509 -fingerprint -sha1 -noout -in $i \    | sed 's/://g' | awk -F= '{print tolower($2)}'done

Compare the output against what is registered in IAM to identify the mismatch.

Update the thumbprint via AWS CLI

bash

aws iam update-open-id-connect-provider-thumbprint \  --open-id-connect-provider-arn arn:aws-cn:iam::<account-id>:oidc-provider/<your-spacelift-hostname> \  --thumbprint-list <new_thumbprint> \  --endpoint-url https://iam.cn-north-1.amazonaws.com.cn

Update via AWS Console

1. Go to IAM → Identity Providers on the China console

2. Click on your OIDC provider

3. Click Manage → Add or remove thumbprints

4. Replace the old thumbprint with the new one

⚠ Make sure you are using the China console (console.amazonaws.cn), not the standard AWS console.

4. Terraform tls_certificate Data Source Using Wrong Cert Index

If you are managing the OIDC provider via Terraform and notice it keeps trying to revert the thumbprint back to a non-working value on apply, the data source is likely pointing at the wrong certificate in the chain.

The tls_certificate data source returns the entire chain as an array:

certificates[0]  ← leaf/server cert  ❌ wrong
certificates[1]  ← intermediate CA
certificates[2]  ← root CA           ✅ what AWS wants

The fix — always use the last certificate in the chain:

hcl

data "tls_certificate" "spacelift" {  url = "https://<your-spacelift-hostname>"}resource "aws_iam_openid_connect_provider" "spacelift" {  url            = "https://<your-spacelift-hostname>"  client_id_list = ["https://<your-spacelift-hostname>"]  thumbprint_list = [    data.tls_certificate.spacelift.certificates[      length(data.tls_certificate.spacelift.certificates) - 1    ].sha1_fingerprint
  ]}

Using length - 1 dynamically grabs the last cert in the chain regardless of depth, so it will not break if an intermediate is added or removed in the future.

Why does the thumbprint change at all?

Note: AWS largely stopped validating OIDC thumbprints for providers backed by well-known CAs (DigiCert, Verisign, etc.) as of 2023. However, AWS China lags behind on these changes — thumbprint validation is still actively enforced in the aws-cn partition, which is why this issue surfaces specifically in China regions.

5. Audience (aud) Claim Mismatch

The client_id_list on the OIDC provider must exactly match the aud claim in the Spacelift-issued JWT. For Spacelift, the audience is typically the same as the issuer URL.

bash

aws iam get-open-id-connect-provider \  --open-id-connect-provider-arn arn:aws-cn:iam::<account-id>:oidc-provider/<your-spacelift-hostname> \  --endpoint-url https://iam.cn-north-1.amazonaws.com.cn \  --query 'ClientIDList'

It should return ["https://<your-spacelift-hostname>"].

Quick Checklist