OIDC JWT Signature Verification Fails

Pega-as-a-Service
, ,
1

Hello,

We are setting up an OIDC authentication flow using a truststore signature that is created from the OpenID Connect Provider’s well-known configuration URL. The keystore is configured using a JWKS URL reference.

Our JWKS contains the following parameters:

  • n

  • e

  • x5c

  • x5t

The JWT issued by our IdP contains the following header values:

  • kid

  • x5t

  • alg

We have verified that both the kid and x5t values in the JWT match the corresponding values in the JWKS. However, Pega still fails during signature verification with the following error:

com.pega.pegarules.pub.PRRuntimeException: The thumbprint match failed against trust store
    at com.pega.platform.securitycore.internal.jwt.JWTSignatureVerifier.getJWSKeySelectorFromPubKey(JWTSignatureVerifier.java:250)
    at com.pega.platform.securitycore.internal.jwt.JWTSignatureVerifier.getJWSKeySelector(JWTSignatureVerifier.java:217)

Caused by: java.io.IOException: Certificate does not exist, Keystore Entry is not either PrivateKeyEntry or TrustedCertificateEntry
    at com.pega.platform.securitycore.internal.jwt.JWTSignatureVerifier.getCertificateUsingThumbprint(JWTSignatureVerifier.java:322)
    at com.pega.platform.securitycore.internal.jwt.JWTSignatureVerifier.getJWSKeySelectorFromPubKey(JWTSignatureVerifier.java:245)

According to the Pega documentation:

When a keystore is created using a URL reference and the JSON Web Key (JWKS) keystore type, Pega fetches the JWKS at runtime and processes it as follows:

  • If the JWKS contains n and e, Pega constructs an RSA public key from those parameters, and a truststore is not used.

  • If the JWKS contains x5c and x5t, Pega attempts to extract the certificates and validate the certificate chain. In this case, the application server/JVM truststore must contain the issuing CA/intermediate certificates.

Our IdP cannot remove the x5c and x5t parameters because they are required by other applications within our organization.

Since we are running on Pega Cloud, we do not believe we have the ability to upload our IdP certificate or CA chain into the underlying application server/JVM truststore.

Questions

  1. When both n/e and x5c/x5t are present in the JWKS, does Pega always prefer certificate-based validation over constructing the RSA public key from n and e?

  2. Is there any configuration that allows Pega to ignore x5c/x5t and fall back to using n and e for signature verification?

  3. Has anyone encountered this issue in Pega Cloud, and if so, how was it resolved?

Our security team strongly prefers using the JWKS URL for automatic key rotation instead of manually uploading certificates into a keystore, as manual certificate management introduces additional operational dependency and maintenance.

Any guidance or recommendations would be greatly appreciated.

2

1…Yes. When x5c and x5t are present, Pega’s JWTSignatureVerifier prioritizes certificate-based thumbprint and chain validation over constructing an RSA public key from n and e. It immediately attempts to look up the certificate in the truststore using the x5t thumbprint, throwing the runtime error if the CA chain is missing.

2…No native Pega configuration or Dynamic System Setting (DSS) allows the engine to ignore x5c/x5t while those parameters exist in the JWKS or JWT header. To force Pega to perform signature verification using n and e, the incoming JWKS payload itself must omit the certificate fields.

3…Yes, this is a common issue in Pega Cloud due to restricted underlying JVM access. Teams resolve it by opening a Pega Global Customer Support (GCS) ticket to import the IdP’s root/intermediate CA certificates directly into the Pega Cloud JVM truststore, or by putting an API proxy in front of the JWKS URL to strip the x5c and x5t attributes.

3

Our IdP JWKS contains both x5c and x5t.

We understand that x5t represents the thumbprint of the JWT signing/leaf certificate.

please clarify:

  1. When both x5c and x5t are present, should Pega use the certificate from x5c[0], or does it require the certificate matching x5t to already exist in the Pega/server truststore?

  2. If the certificate chain is:

    • myorg-jwt-signing-test-2025-08-27.crt — leaf
    • myorg-infra-ca-v2.crt — intermediate
    • myorg-root-ca-v1.crt — root

    do we need to import all three into the truststore, or are Root + Intermediate sufficient?

  3. If the leaf certificate must be imported, would we need to import the new leaf certificate every time the IdP rotates its JWT signing certificate, even though the new certificate is already available in JWKS x5c?

4

  1. When both x5c and x5t are present:
    Pega appears to use x5t to look up the matching certificate in the truststore rather than relying only on the certificate provided in x5c[0]. The error thumbprint match failed against trust store indicates that the certificate matching x5t must be available in the truststore.

  2. Which certificates should be imported:
    Normally, Root + Intermediate would be sufficient for certificate-chain validation because the leaf is already present in x5c[0]. However, in this Pega flow, the leaf certificate may also need to be imported because Pega is performing the x5t thumbprint lookup. So you may need all three: Leaf, Intermediate, and Root.

  3. What happens during certificate rotation:
    If Pega requires the leaf certificate matching x5t to exist in the truststore, then yes, the new leaf certificate would need to be imported whenever the IdP rotates its JWT signing certificate, even if the new certificate is already published in JWKS x5c.

I would recommend confirming this behavior with Pega Support, especially the certificate-rotation scenario, because ideally JWKS x5c should allow the signing certificate to be obtained dynamically without manually importing every new leaf certificate.