<div dir="ltr">Nate,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 22, 2015 at 10:04 AM, Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu" target="_blank">ndk@internet2.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div>
<div>
<div dir="ltr">
<div>Corey,</div>
</div>
</div><span class="">
<br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>I was just trying to use <a href="http://testshib.org/" target="_blank">testshib.org</a> to test an OpenAM SP setup and one thing I ran into is that some of the endpoint URLs in the testshib-providers.xml metadata file are referencing endpoints that
 have a self-signed SSL certificate for some reason.  The problematic URLs are all referencing port 8443 instead of the standard 443 port for SSL.<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>Shibboleth has historically treated back-channel queries as separate services that use separate certificates to avoid the rollover issues that would be incurred by the use of shorter-lived certificates  I’m personally fine with revisiting this, and my
 dogma indicates my preference to use a single port and certificate for all of this.</div>
<div><br>
</div>
<div><a href="https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement" target="_blank">https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement</a></div>
<div><br></div></div></div></blockquote><div><br></div><div>Thanks a lot for your explanation on the separate port for back-channel queries.  I took a quick read through the link you provided but have to confess it didn't help me understand what you meant.  Some googling turned up:</div><div><br></div><div><a href="https://spaces.internet2.edu/display/InCFederation/Back-channel+SAML+Protocols">https://spaces.internet2.edu/display/InCFederation/Back-channel+SAML+Protocols</a><br></div><div><br></div><div>which helped me understand why a separate self-signed certificate is being used for the back-channel endpoints.  </div><div> </div><div>For testing purposes I hacked the metadata and simply changed the endpoints referencing 8443 to 443. Should this work?  (I know it's not advisable in a production system, but I'm just trying to validate a basic SP configuration).  I'm now seeing errors saying "Inbound message issuer was not authenticated." but I'm not sure if this is because I changed the port or if there's some other issue related to my SP configuration causing the issue.</div><div><br></div><div>Regards,</div><div>Corey</div></div></div></div></div>