<div dir="ltr">I did install it through yum as recommended here: 

<a href="https://wiki.shibboleth.net/confluence/display/SP3/RPMInstall">https://wiki.shibboleth.net/confluence/display/SP3/RPMInstall</a>. I just restarted it again for like the 4th time today and now it works again. So I have no idea what changed but it's working now. Thank you for your help. And just to help me with best practices are you saying I should just get my metadata from <a href="http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml">http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml</a> and then filter it to my institution?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 2:08 PM Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Conroy Baltzell <<a href="mailto:baltzell@umich.edu" target="_blank">baltzell@umich.edu</a>> [2019-12-03 19:56]:<br>
> (and I'm hesitant to update anything on the production server<br>
> without testing it on the dev server).<br>
<br>
The way I see it your internal servers are already 100% broken by not<br>
knowing your own IDP. Not sure how things could get worse.<br>
<br>
You don't provide any information on how you installed the SP but if<br>
you did anything other than adding the yum repo as per the docs and<br>
installed via yum then you're probably Doing It Wrong.<br>
<br>
> I didn't realize the SP uses cached metadata so that seems to be the<br>
> most likely suspect. I don't think the problem is<br>
> <a href="https://shibboleth.umich.edu/md/umich-prod-idps.xml" rel="noreferrer" target="_blank">https://shibboleth.umich.edu/md/umich-prod-idps.xml</a> because a lot of<br>
> sites use that and none of them seem to be down. How would I tell if<br>
> it was an expired validUntil?<br>
<br>
I only mentioned that because you said all your Shib SPs refused to<br>
know your IDP around the same time and that you thought no software<br>
changes were involved.<br>
<br>
Right now the above metadata is not expired but you can look what<br>
affected SPs have in the file system, of course.<br>
(/var/cache/shibboleth or somewhere in that vicinity).<br>
<br>
More fundamentally: I personally recommend to our institutions to pull<br>
IDP metadata from the federation aggregate (and filter it down to the<br>
one institutional IDP is desired, for local-only SPs; with MDQ even<br>
that filtering goes away) because then institutions doesn't have to<br>
implement secure, regular signing processes only for the metadata of a<br>
single IDP entity.<br>
But then I'm the federation operator, so I'm probably biased.<br>
<br>
-peter<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>