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

[Nick Roy <nroy AT internet2.edu>]

On 19 Nov 2019, at 8:02, Pål Axelsson wrote:

>> -----Ursprungligt meddelande-----
>> Från: edugain-discuss-request AT lists.geant.org <edugain-discuss-
>> request AT lists.geant.org> För Peter Schober
>> Skickat: den 19 november 2019 12:18
>> Till: Zenon Mousmoulas <zmousm AT noc.grnet.gr>
>> Kopia: Tomasz Wolniewicz <twoln AT umk.pl>; edugain-
>> discuss AT lists.geant.org
>> Ämne: Re: [eduGAIN-discuss] reference for expired certificate warning
>>
>> * Zenon Mousmoulas <zmousm AT noc.grnet.gr> [2019-11-19 11:55]:
>>> I am not suggesting removing the check/warning. I am just trying to
>>> understand where it comes from, so that we can provide an argument to
>>> federation members who are asking why we ask that they update their
>>> expired certificates.
>>
>> Sorry, I was under the (wrong) impression you were asking about some
>> eduGAIN component warning about expired *signing* *certificates* from
>> eduGAIN member federations -- because that's what item 1 on the page you
>> referenced is about:
>> https://wiki.geant.org/display/eduGAIN/Best+Current+Practice
>>
>> So I'll reverse my previous statement (that SAMLMetaIOP does not apply
> to
>> your question) and now state that the /above/ does not apply to your
>> question, but SAMLMetaIOP fully does.
>>
>> You're right that expired certificates maybe have been a concern in the
> past,
>> cf. the 6th bullet in section "Metadata" on the page:
>>
> https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop#Mic
>> rosoftInterop-ADFSV2
>> But that page hasn't been updated for years (and there's also no
> supported
>> Shibboleth software left that would be maintained in the "SHIB2" space
> of
>> that wiki, so it's purely of historical relevance).
>> Chris P. et al. will know all about the current state of affairs trying
> to interop
>> with MS-ADFS, though.
>
> Hi,
>
> The problem with expired certificates still hits ADFS servers.Microsoft is
> using the same TLS library for everything. We had that discussion within
> SWAMID a month ago and did a recheck.
>
> The effect is that your users will not be able to login to a service
> "protected" with ADFS if your IdP has expired certificates andviceversa.
>
> Pål

It’s not just ADFS that has this problem, numerous other bad SAML 
implementations also treat certs in metadata as if they were PKIX and 
incorrectly validate them that way. ADFS is certainly the one we see this 
with the most often. It’s also doubly (quadruply?) unfortunate when combined 
with the following facts:

1) ADFS also cannot deal with multiple keys in entity metadata at one time, 
preventing it from doing graceful key rollover.
2) By default, ADFS generates 2-year self-signed certs for signing and 
encryption operations.
2) ADFS will "helpfully" automatically roll this cert (not just re-sign the 
previous cert, but generate an entirely new keypair a few weeks before the 
old certs expire, without warning.

Nick

>
>> Other than that I guess referring to RFC2119 is all one can do if you
> wanted
>> to know just how weak or strong that RECOMMENDATION from
>> SAMLMetaIOP about unexpired certs is.
>>
>> I /certainly/ have expired certificates in entities' metadata and as
> long as
>> noone complains about systems unable to interop with those (i.e., unable
> to
>> confirm with SAMLMetaIOP, which actually is a formal requirement from
> our
>> technical profile, but that doesn't help with entities registered in
> other
>> federations, for example) I have no intention of forcing a key rollover.
>> Incidently none of these we currently publish to eduGAIN, which is why I
>> haven't spent any time thinking about that.
>>
>> -peter

Attachment: signature.asc
Description: OpenPGP digital signature