Hi,
I understand the issue you are describing.
First, the error condition is correct, but the error message is incorrect. It mentions X509SerialNumber, but that should be X509IssuerName. But this is a relatively minor thing. I have corrected this error message in the 20230720 version of the callout.
Second, according to RFC 5230 section7.1,
Two naming attributes match if the attribute types are the same and the values of the attributes are an exact match after processing with the string preparation algorithm. Two relative distinguished names RDN1 and RDN2 match if they have the same number of naming attributes and for each naming attribute in RDN1 there is a matching naming attribute in RDN2. Two distinguished names DN1 and DN2 match if they have the same number of RDNs, for each RDN in DN1 there is a matching RDN in DN2, and the matching RDNs appear in the same order in both DNs. ..
The current callout follows this directive - it allows the match of DNs only when the order of RDNs is the same. I believe this is correct behavior.
There are platform-embedded libraries that produce a stringified version of a DN, and they respect the order of the sequence in the certificate. If the client in this case is using a platform-based library, then the string form that the client embeds into the signed document (which in your case looks like C=US,ST=xxx,L=xxx,O=xxx,CN=xxx), reflects the actual order of the sequence of RDNs in the signing certificate. The DN of the certificate you supplied (which in your case looks like CN=xxx,O=xxx,L= xxx,ST=xxx,C=US), is created by the Java platform library, which we can presume is correct. These strings are different, therefore the sequence order is different, therefore we should conclude that the certificates are different. The cert identified in the signed document is not the same cert you are supplying in your policy configuration. They're different and the error message is telling you that.
To sort this out, you can use the openssl tool to examine what IT THINKS is the DN for the cert you are specifying in the Validation config, as well as the cert specified by the client during its signing process. I would expect that openssl will give you different DN strings. If you just do a file comparison of the PEM files, you should see a difference as well.
How can you avoid this?
The check that is failing for you, happens when the inbound document identifies the signing certificate via a KeyInfo element that looks like this:
<KeyInfo>
<wsse:SecurityTokenReference wsu:Id="STR-2795B41DA34FD80A771574109162615125">
<X509Data>
<X509IssuerSerial>
<X509IssuerName>C=US,ST=xxx,L=xxx,O=xxx,CN=xxx</X509IssuerName>
<X509SerialNumber>1323432320</X509SerialNumber>
</X509IssuerSerial>
</X509Data>
</wsse:SecurityTokenReference>
</KeyInfo>
One way to avoid this is for the caller (the client) to encode the cert differently into the signed document. I don't know if that is possible for you.
Another way to avoid this is to obtain the exact certificate that the client used during signing., and use that in the configuration for the Validation policy.
A possibility, which I consider to be unlikely, is that there is a bug in the client code that performs the signing, and it is creating the DN string in a manner that does not respect the sequence order, for some reason. If this is the case, then I could introduce a flag to relax the requirement on the ordering of RDNs . This feels wrong to me, but I understand when getting systems to interoperate, it may be necessary.
LinkedIn
Twitter
