Renewal of certificate causes OIDC client signature verification failure
Article ID: 218942
Updated On:
Products
Issue/Introduction
After customer renewed 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 [00038271-154c-1f93-8d57-a38e1e870000] using the [RS256] algorithm due to a signature verification failure: [JWT rejected due to invalid signature. Additional details: [[9] Invalid JWS Signature: JsonWebSignature{"kid":"97c682a4-8e97-4953-8f65-d7f1bba0ce63","alg":"RS256"}->
Same certificate on the same policy server is used for Federation too. Federation transaction is working fine but not on the OIDC Clients.
When access jwk-set-uri: https://gateway.xxxxx.com/affwebservices/CASSO/oidc/sampleClient/jwks, customer does get updated result comparing to old certificate.
One can see 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":"d37axxxx-xxxx-xxxx-xxxx-xxxxxxx","n":"wmhH_......KJh6c2pngzKpVQ"}]}
Working result with old cert:
{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"0003xxxxxxx-xxxx-xxxx-xxxxxxx","n":"uLM......OJ5DST4tyeCX12w"}]}
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, oidc client only has or imported Trusted RootCA cert (issuer chain) provided by siteminder IDP, not the new public cert itself.
Environment
Release : 12.8.03
Component : SITEMINDER FEDERATION SECURITY SERVICES
Cause
Customer can conduct 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 from FWSTrace logs of for the client reported transaction.
Example JSONWebKeySet response
{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"d37axxxx-xxxx-xxxx-xxxx-xxxxxxx","n":"wmhH_......KJh6c2pngzKpVQ"}]}
Copy key from above response example below
{"kty":"RSA","e":"AQAB","use":"sig","kid":"d37axxxx-xxxx-xxxx-xxxx-xxxxxxx","n":"wmhH_......KJh6c2pngzKpVQ"}
Open https://8gwifi.org/jwkconvertfunctions.jsp, use utility for JWK to PEM Convertor.
Key in the above extracted key and convert it into PEM.
You will get Public Key for feed in JWK
Now go to OIDC configuration in siteminder and check the Certificate used for signing for this Client and extract Public Key from certificate using openssl or any tool.
When extracting public key output from pfx, you first needs to export the certificate from pfx file.
Once you have the cert, then run "openssl x509 -pubkey -noout -in mycert.pem", which will give you the output public key.
openssl is available on any CA access gateway server, under ~CA/secure-proxy/SSL/bin location.
Compared the Public key extracted from Certificate (used for signing the token used in Siteminder OIDC configuration) and public Key extracted from JSONWebKeySet response using https://8gwifi.org/jwkconvertfunctions.jsp
They both are identical.
In this use case, result is identical. Which means jwks end point response is correct.
Consider test id_token on web site https://jwt.io/ and choose Algorithm RS256.
In this test, we noticed 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 cery/key signature, even though both admin ui and JWKS endpoint pointed to new cert/key.
How could this be?
In customer's step, they have these steps below. Which normally works for federation, but it will not work for OIDC.
Engineering explained "federation fetches Certificate objects by alias name, but in OIDC the certificate is being fetched by XID link."
"smkeytool.sh -renameAlias -alias newkey -newalias newkey2019
Next rename the new certificate to newkey
smkeytool.sh -renameAlias -alias newkey2020 -newalias newkey
"
The purpose of renameAlias has its practical reason, because they have large number of partners, can not manually go to each fed partner to change signing cert Alias from admin ui.
Cert alias was changed after oidc configuration object 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 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 value, which would indicate a data corruption.
Customer needs to edit particular object Xid: CA.FED::Certificate@d37a......, using XPSExplorer.
This object is used by a particular OIDC provider.
CertificateGUID: CA.CDS::Certificate@5f379485-xxxx-xxxx-xxxx-xxxx0, which is wrong object XID.
change to Xid: CA.CDS::Certificate@000769b7-xxxx-xxxx-xxxx-xxxx0, which is the correct object XID, and this XID can be obtained/verified from CA.CDS::Certificate object list directly.
For example (In XPSExplorer, CertificateGUID has different value from SMPolicyReader tool):
------------------------- Object Meta Data ------------------------
XID: CA.FED::Certificate@1df05bd9-4faa-4686-97b0-76f404c1d3d6
Actual Class: (not set)
Base Class: CA.FED::Certificate
In Cache: yes 5
Created: 2020-07-09 17:12:09 GMT
By: siteminder (via RemoteAPI)
--------------- Attributes from CA.FED::Certificate ---------------
Alias = "newkey"
CertificateGUID = CA.CDS::Certificate@000769b7-xxxx-xxxx-xxxx-xxxx0
FIPSApproved = true
IssuerDN = "C=IN,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
SerialNumber = "00xxxxxxxxxxxxx"
Type = <KeyEntry>
Once CertificateGUID link xid is corrected, IssuerDN and SerialNumber need to be updated to the matching certificate information too.
IssuerDN and SerialNumber can be obtained/verified from CA.CDS::Certificate object list directly or xml policy store export file.
Additional Information
DE506771
Feedback
