-
Hello everyone, I am reaching out to the community because I am stuck on a really tricky issue concerning the verification of an RSA signature via the OpenSSL extension of PHP. Versions:
Problem: In most cases, the verification works correctly (tested in CLI, in a minimal PHP script, and in the Symfony application). But for certain values, the verification fails in Symfony with an error such as ‘invalid padding’ or ‘padding check failed’. I was able to isolate a string that generates this error. And the fact is that this ONLY happens on Symfony: in CLI or with the script, it's OK. I compared the variables in base64 and they are strictly identical. In my case, the only variable that changes is the date. But the string is always the same length. The string is always formatted in the same way: For example, the following string will not work: But this one will work, only replacing 7 by 6 at the end: I cannot explain this behaviour at all, let alone the fact that it only occurs on Symfony and not on a classic PHP script. What I have already checked:
I'm completely lost on this one. I've easily spent the whole day on it. Many thanks to anyone who tries to help me! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
I finally found the solution to my problem, and I'm sharing it here in case it can help anyone else. In my code, I isolated the signature this way:
I was foolishly following the Paybox documentation, which said to first use urldecode and then base64_decode... It turns out that PHP already applies urldecode natively when retrieving the parameter, whether via
Why this didn't happen on all strings, yet replacing a 6 with a 7 generated it, I have no idea. I suppose it's related to special characters in the signature that were corrupted because of this double decoding, and which only appeared on certain patterns. I hope this will be useful to someone. |
Beta Was this translation helpful? Give feedback.
I finally found the solution to my problem, and I'm sharing it here in case it can help anyone else.
In my code, I isolated the signature this way:
I was foolishly following the Paybox documentation, which said to first use urldecode and then base64_decode... It turns out that PHP already applies urldecode natively when retrieving the parameter, whether via
$request->get(“sign”)
or via$_GET[“sign”]
. So, the following simple change solved the problem:$decodedSign = base64_decode($sign);
Why this didn't happen on all strings, yet replacing a 6 with a 7 generated it, I have no idea. I suppose it's related to sp…