Configuring additional signing/encryption certificate/key pairs for IDP 3.4.6
peter.schober at univie.ac.at
Fri May 29 09:58:52 UTC 2020
* Mak, David <d.mak at northeastern.edu> [2020-05-28 23:33]:
> We have a vendor who is complaining about a SHA1 signed RSA2048 self
> signed cert (not due to expire until 2032) and how they need to
> configure an exception to accept our signed responses (that they
> require) so we looked into creating a new SHA256 MD/signed RSA2048
> cert and added it as per:
Not that this will matter much but that means they have a bug, no?
(Just so that we're clear about this at least here.)
The signature on a self-signed certificate by its nature is
meaningless (because its self-asserted so provides no more information
nor trust than what's being signed), so is the signature algorithm
used in that signature.
The only useful thing in such a certificate is the public key itself
and it's trustworthy only because of trustworthy exchange of the SAML
2.0 metadata its embedded into.
If so you should be telling the vendor that so that maybe they could
fix this and spare other customers to perform the dance you're now
having to go through to work around their bug.
More information about the users