Shibboleth Identity Provider Security Advisory [4 October 2017]

Baron Fujimoto baron at hawaii.edu
Thu Nov 9 15:42:29 EST 2017


On Thu, Nov 09, 2017 at 02:24:35PM -0600, Michael A Grady wrote:
>
>> On Nov 9, 2017, at 2:15 PM, Baron Fujimoto <baron at hawaii.edu> wrote:
>> 
>>> No, the LDAP server's cert (or CA for that cert is often the better choice.)
>> 
>> Hmm, does that make it fragile in the sense that we have to be cognizant
>> of the LDAP server's expirations and such (if using just the LDAP server's
>> cert)?
>> 
>> By CA, do you mean just the root cert for the CA issuing the LDAP server's
>> cert, or a cert that encompasses some or all of the certificate chain?
>> Even there, do we need to worry about expiration of any of the CA certs?
>> 
>> I suppose if we upgrade to V3.3.2 before any of the aforementioned
>> certificate expirations, it's probably moot since the underlying problem
>> get's resolved by the underlying ldap component fix?
>
>So you are updating Java frequently enough to keep its default ca-certs file up-to-date, but you aren't carefully managing your LDAP server cert? I'd imagine you actually have good practices around the LDAP server cert. (It will be moot in the future, Shib won't give you another option other than a Shib-specific cert store anyways.)
>

We upgrade our Java pretty routinely, so our Java cacerts file should
presumably be current. But we don't manage the LDAP host or its certs
ourselves so having to maintain a local copy of its cert is something that
would introduce a new tracking and management process for us. Since it's
managed by another group, if they make uncommunicated and uncoordinated
changes doesn't this risk breaking our IdP? Unless I'm fundamentally
misunderstanding something here (not ruling that out).

>The least fragile solution, assuming you have good dev ops around your LDAP server, is to store the CA cert, in PEM format, in the IdP's trustfile store. And "do the right thing" on the LDAP server, keeping its cert up-to-date and being sure it serves out the full chain of needed intermediate certs. So the expiration part is all handled, as it should be, on the LDAP server. Presumably the number of times you need to deal with the actual Root CA cert expiring is pretty rare/infrequent. Now, if you change the Root CA for your LDAP server cert, you will need to update the IdP's trustfile store. But you just record and keep track of any such dependencies.

Ok, I think I understand re the root and intermediate certs, but I'm still
unclear on what happens when the LDAP cert gets updated in the course of
its normal lifecycle. If this is a dependency that's tightly coupled to
the IdP's operation what is the best practice or recommendation for
handling the rollover of the LDAP server's cert?

--
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum


More information about the users mailing list