Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] EntityDescriptor-embedded signature with invalid reference URI in eduGAIN metadata

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive

Re: [eduGAIN-discuss] EntityDescriptor-embedded signature with invalid reference URI in eduGAIN metadata


Chronological Thread 
  • From: Peter Schober <peter.schober AT univie.ac.at>
  • To: edugain-discuss AT lists.geant.org
  • Subject: Re: [eduGAIN-discuss] EntityDescriptor-embedded signature with invalid reference URI in eduGAIN metadata
  • Date: Wed, 18 Sep 2019 12:26:11 +0200
  • Organization: ACOnet

Hoi Dick,

* Dick Visser <dick.visser AT geant.org> [2019-09-18 11:48]:
> If a signing certificate is issued by Let's Encrypt, then it is highly
> likely that it will be automagically replaced at regular intervals,
> thereby breaking things.
> Although technically correct, IMHO this should trigger an error.

Good point.

As long as the key (modulus) remained the same many of our systems (at
least of the Shibboleth and SimpleSAMLphp variety) wouldn't even
notice: They wouldn't notice if you replaced the cert every
day/week/month and they wouldn't notice if the SP failed to update the
metadata and kept an expired cert in there (as long as the SP has the
matching private key configured into its SP software).

Whether that's how (any, most, all) letsencrypt clients work (keeping
the private key the same and only renewing the certificate) I don't
know. I agree it sounds very brittle.

Of course the aforementioned "immunity" of may not apply to lesser
SAML implementations that do not conform to OASIS SAML MetaIOP[0] (and
therefore also do not conform to saml2int), and even MetaIOP
RFC2119-RECOMMENDS that published certificates are unexpired.
(The eduGAIN SAML Profile[1] does not contain language mandating
MetaIOP support, that was removed during the consultation process[2],
AFAIR.)

There are of course legitimate SAML SPs using commercial web PKIX
certificates also within SAML (for no good reason), e.g. many of the
academic publishers. It would be interesting to see what happens
should the maximum validity period of (other) CAs keep approaching
that of letsencrypt certificates and whether that would trigger those
SPs to move to self-signed certs for SAML, or whether it would simply
lead to or exacerbate the problem you're describing here.

I agree that a letsencrypt-issued cert in SAML metadata is a red flag
and I should make a note to add a check to our registeration checks.
Not sure what to do with published entities carrying such cert in
metadata, though.

-peter

[0] https://wiki.oasis-open.org/security/SAML2MetadataIOP
[1] https://technical.edugain.org/doc/eduGAIN-saml-profile.pdf
[2] https://wiki.geant.org/display/eduGAIN/eduGAIN+SAML+Profile+Consultation



Archive powered by MHonArc 2.6.19.

Top of Page