Notice from Adobe about IdP SHA-1 certificates
peter.schober at univie.ac.at
Tue Jul 21 12:21:21 UTC 2020
* Yeargan, Yancey <Yancey.Yeargan at untsystem.edu> [2020-07-15 23:52]:
> Just a heads-up. I received this notice from Adobe saying that
> identity provider certificates must be signed using SHA-256 by end
> of October.
Can someone share some concrete technical information about this
issue? We're getting similar requests from our community and I can't
make heads or tails of the answers provided so far in this thread.
(Not having any involvement with the vendor because *of* *course* it
does not support multi-party federation.)
So contrary to how this reads (also) to me, are people here saying
this is about their own SP certificate, that in fact they are changing
their SP certificate?!
If not, are people actually considering to change their IDP key pair
(or adding another, one only for use with that vendor) based solely on
the nonsensical request of a vendor to change the digest algorithm
on a (very likely) self-signed certificate?
And even if Adobe (with either SP implementation, I hear ther are two:
one okta.com and another one?) absolutely refused to accept SAML
assertions/reponses that are signed with a certificate they detect as
using the sha1 digest algo -- why would I change my IDP certificate
when I could simply re-wrap that same key/modulus into another
self-signed certificate using the sha256 digest algo and upload that
re-wrapped certificate to their self-service consone?
(Or is there hard evidence that they not only use the certificate on
record for sha1 digest checking but also that they require the
certificate embedded in the signed SAML assertion/response to
literally match the certificate they have on record -- not that simply
the signature can be validated?)
 Assuming the IDP certificate is self-signed there is *zero* trust
to be derived from the (self-)signature of that certificate (i.e.,
subject == issuer, something claiming it is itself by itself saying
so) and consequently the digest algorithm used in that signature is
also completely meaningless: It does not confirm or make trustworthy
any part of the certificate (trust needs to come from elsewhere!) and
therefore the algorithm used in calculating an irrelevant signature is
I.e., there is nothing to gain from changing the digest algo of your
IDP signing certificate other than possibly to please people who have
no idea how this works or what any of this means, which certainly is
one road to hell.
More information about the users