Problem
MSAL prefers PS256/PSS for certificate client assertions against Microsoft Entra authorities. Some certificate private-key providers reject RSASignaturePadding.Pss and throw CryptographicException, even though the same key can sign successfully with PKCS#1 v1.5.
Certificate metadata and legacy APIs are not reliable capability signals. A certificate may expose RSACryptoServiceProvider through one API while the RSA instance MSAL uses can sign PSS successfully.
Expected behavior
MSAL should handle this internally without caller configuration:
- Attempt the preferred PS256/PSS assertion first.
- If PSS signing throws
CryptographicException, rebuild the JWT header as RS256 with x5t and retry using PKCS#1 padding.
- Reuse the same encoded payload so claims and
jti remain stable.
- Preserve PS256/PSS for providers that support it.
- Continue including
x5c when requested.
Test coverage
Add an HTTP-pipeline test that performs normal AcquireTokenForClient, forces the cryptography provider to reject PSS, inspects the posted client_assertion, and verifies its RS256 header and PKCS#1 SHA-256 signature.
Problem
MSAL prefers PS256/PSS for certificate client assertions against Microsoft Entra authorities. Some certificate private-key providers reject
RSASignaturePadding.Pssand throwCryptographicException, even though the same key can sign successfully with PKCS#1 v1.5.Certificate metadata and legacy APIs are not reliable capability signals. A certificate may expose
RSACryptoServiceProviderthrough one API while the RSA instance MSAL uses can sign PSS successfully.Expected behavior
MSAL should handle this internally without caller configuration:
CryptographicException, rebuild the JWT header as RS256 withx5tand retry using PKCS#1 padding.jtiremain stable.x5cwhen requested.Test coverage
Add an HTTP-pipeline test that performs normal
AcquireTokenForClient, forces the cryptography provider to reject PSS, inspects the postedclient_assertion, and verifies its RS256 header and PKCS#1 SHA-256 signature.