<div dir="ltr">Thanks Peter, I did finally track it down, it was indeed SSL ciphers. We use our LB for SSL offloading .. the new SSL certificate configuration didn't have all the Ciphers that were used in the previous config ... once we added the needed cipher we were back in business. Thanks for your response.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div></div><div><br></div><div>Brad Mathis</div><div>IT Principal Systems Analyst</div><div>Infrastructure Services - Applications<br></div><div>Pima Community College<br></div><div>520.206.4826<br></div><div><a href="mailto:bmathis@pima.edu" target="_blank">bmathis@pima.edu</a></div></div><div><br></div><div><img src="https://docs.google.com/a/pima.edu/uc?id=0B4QEFWYNTFJATTZySzROc0JISEk&export=download" width="200" height="150"><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 2:14 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">* Mathis, Bradley <<a href="mailto:bmathis@pima.edu" target="_blank">bmathis@pima.edu</a>> [2019-06-07 20:58]:<br>
> So my first thought was OH I need to update the cacerts file on the<br>
> shib server with the new SSL for our cas server ...<br>
<br>
FYI, I'd expect a "cacert" file to contain certificates of CAs,<br>
i.e. Certification Authorities. So unless the new CAS server uses a<br>
new and different (private?) Certificate Authority to sign the CAS<br>
server certificate messing with "cacerts" wouldn't fix anything.<br>
I know nothing about CAS but all an SSL client needs is a set of<br>
trust anchors (CA cert files) and an SSL server that serves up a<br>
complete certificate chain rooted in one of the trust anchors.<br>
Imagine every web browser would need to perform some kind of update<br>
each time a web server changed its SSL certificate...<br>
<br>
> here the error I see in the idp-process.log<br>
> <br>
> 11:14:37.042 - ERROR [org.jasig.cas.client.util.CommonUtils:406] - Remote<br>
> host closed connection during handshake<br>
> javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake<br>
[...]<br>
> Caused by: java.io.EOFException: SSL peer shut down incorrectly<br>
<br>
I'd start with the server logs from the server that does TLS/SSL for<br>
CAS and maybe increase the log levels there. Failing that you can<br>
try to do the same on the SSL client side (i.e. the IDP).<br>
<br>
Maybe the IDP's JVM tries to use ciphers the CAS server doesn't accept<br>
anymore or something like that. You said IDPv2 so the whole OS and VM<br>
is likely many, many years old.<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>