Renewal of certificate causes OIDC client signature verification failure
Article ID: 218942
Updated On:
Products
Issue/Introduction
After renewing the certificate, all OIDC Clients are generating invalid signature errors upon validation on the jwks endpoint.
[6/17/21 21:09:46:050 EDT] 000000d6 ibm.ws.security.openidconnect.common.OidcCommonClientRequest E CWWKS1756E: Validation failed for the ID token requested by [<value>] using the [RS256] algorithm due to a signature verification failure: [JWT rejected due to invalid signature. Additional details: [[9] Invalid JWS Signature: JsonWebSignature{"kid":"<value>","alg":"RS256"}->
Same certificate on the same Policy Server is used for Federation too.
Federation transaction is working fine but not with the OIDC Clients.
When access jwk-set-uri: https://gateway.example.com/affwebservices/CASSO/oidc/sampleClient/jwks, no updated result is given, comparing to old certificate.
Both kid and public key value are changed to new certificate, however, the signed token signature can not pass client side signature validation.
Non-Working result with new cert:
{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<value>","n":"<value>"}]}
Working result with old cert:
{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<value>","n":"<other_value>"}]}
Here is a quick breakdown of what each property represents in JWT (not all are included):
alg: is the algorithm for the key;
kty: is the key type;
use: is how the key was meant to be used. For the example above, sig represents signature verification;
x5c: is the x509 certificate chain;
e: is the exponent for a standard pem;
n: is the moduluos for a standard pem;
kid: is the unique identifier for the key;
x5t: is the thumbprint of the x.509 cert (SHA-1 thumbprint);
At this point, the OIDC Client only has or imported Trusted Root CA cert (issuer chain) provided by SiteMinder Identity Provider (IdP), not the new public certificate itself.
Cause
Conduct the below exercise to ensure that any mismatch of certificates during the signing of Token and JWKS response from SiteMinder side.
Identify problematic JWKS response from SiteMinder side as reported by Client.
Extract JSONWebKeySet response FWSTrace log line from the client reported transaction.
Sample of JSONWebKeySet response
{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<value>","n":"<value>"}]}
Copy key from above response sample below
{"kty":"RSA","e":"AQAB","use":"sig","kid":"<value>","n":"<other_value>"}
Open https://8gwifi.org/jwkconvertfunctions.jsp, use utility for JWK to PEM Convertor.
Key in the above extracted key and convert it into a PEM format.
The Public Key for feed in JWK will be generated;
Now, go to OIDC configuration in SiteMinder AdminUI, and check the Certificate used for signing for this OIDC Client and extract the Public Key from certificate using OpenSSL or any tool.
When extracting public key output from PFX, first export the certificate from PFX file.
Once having the certificate, then run "openssl x509 -pubkey -noout -in <filename>.pem" command, which will give the output Public Key.
Openssl command is available on any CA Access Gateway (SPS) server, under {home_SPS}/SSL/bin location.
Compared the Public key extracted from the Certificate (used for signing the token used in SiteMinder OIDC configuration) and the Public Key extracted from JSONWebKeySet response using https://8gwifi.org/jwkconvertfunctions.jsp
They are both identical.
In this use case, result is identical. Which means jwks end point response is expected.
Consider test id_token on the website https://jwt.io/ and choose Algorithm RS256.
In this test, note that new id_token can only be signature verified by using old PUBLIC KEY.
The root cause is that Policy Server signed actual OIDC Token with old cert/key pair signature, even though both AdminUI and JWKS endpoint pointed to new cert/key.
How could this be?
This can occur when following these steps below. Which normally works for Federation, but it will not work for OIDC.
Federation fetches the Certificate objects by alias name, but in OIDC the certificate is being fetched by XID link.
# smkeytool.sh -renameAlias -alias <newkey> -newalias <new_key>
Next, rename the new certificate to <newkey>
# smkeytool.sh -renameAlias -alias <new_key> -newalias <newkey>
The purpose of renameAlias has its practical reason, because having a large number of partners, can not manually go to each federation partner to change signing certificate Alias from the AdminUI.
The Certificate alias was changed after OIDC configuration object is created, hence it causes particular object to be corrupted. This data inconsistency between (alias and CertificateGUID) for any CA.FED::Certificate object has to be fixed.
Resolution
When loading the Policy Export file using SMPolicyReader tool, view CA.FED::Certificate, all Alias and CertificateGUID value should be the same, like alias "<newkey>".
If they have different values, which would indicate a data corruption.
Edit the particular object Xid: CA.FED::Certificate@<value>, using XPSExplorer.
This object is used by a particular OIDC provider.
CertificateGUID: CA.CDS::Certificate@<value>, which is wrong object XID.
Change to Xid: CA.CDS::Certificate@<other_value>, which is the correct object XID, and this XID can be obtained/verified from CA.CDS::Certificate object list directly.
To illustrate:
(In XPSExplorer, CertificateGUID has different value from SMPolicyReader tool)
------------------------- Object Meta Data ------------------------XID: CA.FED::Certificate@<value>Actual Class: (not set)Base Class: CA.FED::CertificateIn Cache: yes 5Created: 2020-07-09 17:12:09 GMTBy: siteminder (via RemoteAPI)--------------- Attributes from CA.FED::Certificate --------------- Alias = "<newkey>" CertificateGUID = CA.CDS::Certificate@<value> FIPSApproved = true IssuerDN = "C=IN,<value>" SerialNumber = "<value>" Type = <KeyEntry>
Once CertificateGUID link xid is corrected, IssuerDN and SerialNumber need to be updated with the matching certificate information too.
The IssuerDN and SerialNumber can be obtained/verified from CA.CDS::Certificate object list directly or from the XML Policy Store export file.
Additional Information
DE506771
Feedback
