AbstractPKIXTrustEngine::checkEntityNames currently matches the configured key names against 3 different properties of the certificate to be checked to decide whether it is acceptable to continue to the PKIX validation stage:
- The full subject DN (RFC2253-formatted)
- The subject's last CN RDN
- The set of DNS/URI subjectAlternateNames
We are running a Shibboleth SP instance that interacts with an IDP with peculiar signature certificate naming conventions, for which none of the above methods work:
The IDP in question uses signature certificates with subject DNs of the form:
And so on. Each time a key rollover happens, a new certificate is issued and the CN=A,B,C,... RDN is incremented. There are no subject alternate names in the signature certs.
Because the full DN changes on every rollover, and because the last CN RDN is the CN=A,B,C one and not the CN=theidp one, none of the default name matching options work for this IDP.
Asking the IDP's organization to change their naming convention is not a likely option in this case, as this convention is deeply ingrained in their certificate ecosystem. Incidentally, the IDP's organization documented method for checking the subject DN is to verify that the DN has the suffix "CN=theidp,O=theorganization".
I'm happy to patch Shibboleth's PKIXTrustEngine and run a custom build to make that happen, but this requires overriding AbstractPKIXTrustEngine::checkEntityNames, which is currently not possible because it is not virtual.
I can patch the method to be virtual in xmltooling as well, but then I have to maintain two separate patches for two separate codebases that are mutually dependent, which is cumbersome and error-prone (things will fail silently if I ever forget to apply the xmltooling patch when building Shibboleth).
Therefore, would you be willing to consider making AbstractPKIXTrustEngine::checkEntityNames virtual so that users of xmltooling can override it without having to patch xmltooling itself? I realize that this constitutes an ABI change and is therefore not likely to happen any time soon, but it would simplify things for these kind of use cases.