<div dir="ltr">Are you saying that, after the rpm update, I should leave the existing 

<span style="color:rgb(80,0,80)">shibboleth2.xml and </span>

<span style="color:rgb(80,0,80)">shibboleth2.xml.rpmnew alone ?</span><div><span style="color:rgb(80,0,80)">I recalled that, after the rpm update, I got some error ( I do not recall what it was now ). That prompted me to look in /etc/shibboleth and realized there was a </span><span style="color:rgb(80,0,80)">shibboleth2.xml.rpmnew, which triggered me to do the modifications.</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 31, 2019 at 4:37 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</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">On 1/31/19, 7:29 PM, "users on behalf of William Chan" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:wchan999@gmail.com" target="_blank">wchan999@gmail.com</a>> wrote:<br>
<br>
> I did carefully renamed  shibboleth2.xml.rpmnew to  shibboleth2.xml .  Carefully modified <ApplicationDefaults .. >,<br>
> <SSO ..> and  <MetadataProvider ..> appropriately. <br>
<br>
If you deliberately do that, you'd break it, pretty transparently since it's telling you exactly what's wrong. That's not how upgrades are done (or documented).<br>
<br>
-- Scott<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Thu, Jan 31, 2019 at 4:06 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>> wrote:<br>
<br>
<br>
You can't possibly get that result unless the original installation was untouched and never used, in which case the package should have just been removed first. If shibboleth2.xml was unmodified (which is impossible for a functioning SP doing any real work),<br>
 then the upgrade would probably overwrite that file with the new one but wouldn't generate the new keypairs, and it would be out of sync. That's conceivable but was not something anticipated.<br>
<br>
In any real upgrade, the modified shibboleth2.xml would be untouched (it would create shibboleth2.xml.rpmnew), and still referencing the old single keypair, and you wouldn't get those messages.<br>
<br>
And no, it's not a working system. It would fail to decrypt assertions and nobody could login, outside of IdPs not encrypting their assertions.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <br>
<a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a> <<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 <br>
<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a> <mailto:<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a>><br>
<br>
<br>
<br>
<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>