Open sayandaw opened 1 year ago
According to RFC 7512, which can be found at https://datatracker.ietf.org/doc/rfc7512/, this behaviour is expected.
Use of the "pin-value" attribute may have security-related consequences. Section 6 should be consulted before this attribute is ever used. Standard percent-encoding rules SHOULD be followed for the attribute value.
"%" in SPN Secret fails decoding between OpenSSL <> LIBP11
Issue
Scenario:
The SPN's secret has a "%" Then when OpenSSL uses the LIBP11 library and calls the mHSM library, the "%" passed as headers is decoded and hence the OpenSSL connection fails with
Error: "error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app 'XXXX'"
Explanation:
As per MS. please note that this behaviour is expected according to section 2.3. PKCS #11 URI Scheme Syntax of https://datatracker.ietf.org/doc/rfc7512/ .
When libp11 encounters a "%" character in any attribute value, it considers it as a percent-encoded character and attempts to decode it, thereby removes it. Therefore, if we have "%" in any attribute value, such as client secret, we should encode it. The value of option “-key” is PKCS#11 URI that OpenSSL forwards to libp11 to access the key stored in HSM.
It is worth noting that the OpenSSL library calls the libp11 library, which in turn calls our TLS offload library. The libp11 library provides a higher-level interface compared to the PKCS#11 library, and it is designed to integrate with applications that use OpenSSL.
Workaround
Don't use an SPN which has "%" in it's secret.