SSL Error: alert internal error

[Christopher Peters]

>From the IDP side, there's not even a mention of a connection attempt.
 Unfortunately, I only have the IDP logs, not the Tomcat logs because we
reverted the changes before saving those logs.  That said, I did get some
decent logs from a service provider:

2013-07-24 21:22:42 DEBUG XMLTooling.SOAPTransport.CURL [18]: sending SOAP
message to
https://shib.nacs.uci.edu:8443/idp/profile/SAML1/SOAP/AttributeQuery****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: Connection #0 seems to
be dead!****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: Closing connection #0****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: SSLv3, TLS alert, Client
hello (1):****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: About to connect() to
shib.nacs.uci.edu port 8443 (#0)****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]:   Trying 128.195.182.15
...****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: connected****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: Connected to
shib.nacs.uci.edu (128.195.182.15) port 8443 (#0)****

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: SSL re-using session ID**
**

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: SSLv3, TLS handshake,
Client hello (1):****

*2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: SSLv3, TLS alert,
Server hello (2):*

*2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: error:14094438:SSL
routines:SSL3_READ_BYTES:tlsv1 alert internal error*

2013-07-24 21:22:42 DEBUG XMLTooling.libcurl [18]: Closing connection #0****

2013-07-24 21:22:42 ERROR Shibboleth.AttributeResolver.Query [18]:
exception during SAML query to
https://shib.nacs.uci.edu:8443/idp/profile/SAML1/SOAP/AttributeQuery:
CURLSOAPTransport failed while contacting SOAP endpoint (
https://shib.nacs.uci.edu:8443/idp/profile/SAML1/SOAP/AttributeQuery):
error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error****

2013-07-24 21:22:42 ERROR Shibboleth.AttributeResolver.Query [18]: unable
to obtain a SAML response from attribute authority****

2013-07-24 21:22:42 DEBUG Shibboleth.SessionCache [18]: creating new session
****

2013-07-24 21:22:42 DEBUG XMLTooling.StorageService.MEMCACHE [18]:
readString ctx: Logout - key: _afdbcad82202b4d57962d226d48469c2****

2013-07-24 21:22:42 DEBUG XMLTooling.StorageService.MEMCACHE [18]: Key
Logout:_afdbcad82202b4d57962d226d48469c2 not found in memcache...****
2013-07-24 21:22:42 DEBUG Shibboleth.SessionCache [18]: storing new
session...

It's just not telling *me* very much.

On our end, all we have is:

Jul 24 21:22:39 shib1.service.uci.edu [Shibboleth-Access:73]
20130725T042239Z|******|shib.nacs.uci.edu:443|/profile/Shibboleth/SSO|
Jul 24 21:22:40 shib1.service.uci.edu [Shibboleth-Access:73]
20130725T042240Z|******|shib.nacs.uci.edu:443|/profile/Shibboleth/SSO|
Jul 24 21:22:40 shib1.service.uci.edu [Shibboleth-Audit:745]
20130725T042240Z|urn:mace:shibboleth:1.0:profiles:AuthnRequest||*****|urn:mace:shibboleth:2.0:profiles:saml1:sso|urn:mace:incommon:
uci.edu
|urn:oasis:names:tc:SAML:1.0:profiles:browser-post|_0f814169c5b80a7d21cdf07aa3d2d21e|*****|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||_afdbcad82202b4d57962d226d48469c2|_66780903f495663db2fabd5a635ec2c2,|
Jul 24 21:22:45 shib1.service.uci.edu [Shibboleth-Access:73]
20130725T042245Z|98.112.170.83|shib.nacs.uci.edu:443
|/profile/Shibboleth/SSO|

Which isn't anything, other than a lack of access attempt.

Chris


On Mon, Jul 29, 2013 at 1:13 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 7/29/13 4:05 PM, "Christopher Peters" <cjpeters at uci.edu> wrote:
> >
> >You're right.  There is something I overlooked, and you saying this made
> >me really think about what I was missing.  It was potentially major too,
> >it just was a blip in the upgrade process that caused me to forget it.
> >
> >We changed java versions.
>
> If that caused this error, I would say you aren't using Apache. That would
> leave many other possible culprits, like Tomcat, etc.
>
> >When I was doing the upgrade, launching the idp software failed because
> >we had a path issue pointing to an old version of java (1.5.0_14).  So I
> >fixed the path to point to 1.6.0_20. (something that had been installed
> >the whole time but never used).
>
> You should use 1.7 unless you're using Terracotta and have to stick with
> 1.6.
>
> >Man, I always feel so dumb after posting here.  Anyway, that's what it's
> >for.  What are your thoughts on this being the culprit?
>
> I don't see it.
>
> Maybe something is happening that isn't TLS-related and is maybe aborting
> the requests mid-way and resulting in that error, but there should be
> evidence of something somewhere in the logs. If the requests are
> demonstrably never getting into the IdP, then there's no way this is Java
> or the IdP.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Chris Peters
Middleware Services Developer
Office of Information Technology - NSP
(949) 824-6845
cjpeters at uci.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130729/fb77895a/attachment.html