[Shib-Users] SSL error with a Shib 2 SP and TestShib-1 IDP
Bell D.
The University of Southampton (a member of the UK Access Management Federation) is working with Penn State University (a member of the InCommon Federation) to allow members of Penn State to logon to a resource (Blackboard in this case) at the University of Southampton. The service provider looks like this:
- Shibboleth 2.1 SP
- Apache 1.3
- Blackboard 8
- Solaris 10
- Member of UK Access Management Federation
The IDP we are trying to work with looks like this:
- Member of TestShib 1
- Shibboleth 1.3 IDP
- Apache 1.3
- (I'm not sure of the other details)
The Service Provider has been configured with the metadata for the UK Federation, InCommon and TestShib. The IDP has been configured with the metadata for the Service Provider (I believe through having the metadata for the UK Federation loaded).
Sadly we have hit an error we do not understand. When a user attempts to logon to the SP they are redirected to the IDP, the logon, and then they are redirected back to the SP with a SAML assertion. The SP then attempts to contact the AA service at the IDP but this is where it fails:
"CURLSOAPTransport failed while contacting SOAP responder: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure"
Here are our logs on the SP (taken some time ago, but the problem persists today!):
http://www.soton.ac.uk/~db2z07/shibd.log.txt
http://www.soton.ac.uk/~db2z07/transaction.log.txt
I have found another reference on this mailing list relating to the problem we are seeing here:
https://mail.internet2.edu/wws/arc/shibboleth-users/2009-06/msg00066.html
However that thread does not appear to have a solution to the problem.
We have successfully managed to get another TestShib IDP to work with the same Service Provider. The configuration of the other TestShib IDP is:
- Shibboleth 1.3 IDP
- Apache 2.2
- Red Hat Enterprise Linux 5.3
- Member of TestShib 1
Does anybody have any ideas? Thanks in advance!
Cheers,
--
David Bell
UNIX Systems Administrator
University of Southampton
d.b...@soton.ac.uk
02380 592403
Chad La Joie
Bell D. wrote:
> Does anybody have any ideas? Thanks in advance!
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
David Bell
> Do NOT use TestShib for this, it's not meant for this, and it's insecure.
Hello,
We are only going to be using TestShib for testing - not in production!
The reason is that Penn State using TestShib for their test IDP. We
wanted to get this working before moving on to test against their
production Identity Provider.
Cheers,
David
Mark K. Miller
On Tue, 16 Jun 2009, Bell D. wrote:
> The IDP we are trying to work with looks like this:
>
> - Member of TestShib 1
> - Shibboleth 1.3 IDP
> - Apache 1.3
> - (I'm not sure of the other details)
Not sure what other details may be needed. But I'll try to provide
whatever I can, if someone is wondering.
Mailvaganam, Hari
Please forward the relevant snippets from the metadata files (IdP & SP)
Regards,
Hari
-----Original Message-----
From: Bell D. [mailto:D.B...@soton.ac.uk]
Sent: June 16, 2009 3:52 AM
To: shibbole...@internet2.edu
Subject: [Shib-Users] SSL error with a Shib 2 SP and TestShib-1 IDP
Hello,
The University of Southampton (a member of the UK Access Management Federation) is working with Penn State University (a member of the InCommon Federation) to allow members of Penn State to logon to a resource (Blackboard in this case) at the University of Southampton. The service provider looks like this:
- Shibboleth 2.1 SP
- Apache 1.3
- Blackboard 8
- Solaris 10
- Member of UK Access Management Federation
- Member of TestShib 1
- Shibboleth 1.3 IDP
- Apache 1.3
- (I'm not sure of the other details)
Sadly we have hit an error we do not understand. When a user attempts to logon to the SP they are redirected to the IDP, the logon, and then they are redirected back to the SP with a SAML assertion. The SP then attempts to contact the AA service at the IDP but this is where it fails:
"CURLSOAPTransport failed while contacting SOAP responder: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure"
Here are our logs on the SP (taken some time ago, but the problem persists today!):
http://www.soton.ac.uk/~db2z07/shibd.log.txt
http://www.soton.ac.uk/~db2z07/transaction.log.txt
I have found another reference on this mailing list relating to the problem we are seeing here:
https://mail.internet2.edu/wws/arc/shibboleth-users/2009-06/msg00066.html
However that thread does not appear to have a solution to the problem.
We have successfully managed to get another TestShib IDP to work with the same Service Provider. The configuration of the other TestShib IDP is:
- Red Hat Enterprise Linux 5.3
Scott Cantor
> Sadly we have hit an error we do not understand. When a user attempts to
> logon to the SP they are redirected to the IDP, the logon, and then they are
> redirected back to the SP with a SAML assertion. The SP then attempts to
> contact the AA service at the IDP but this is where it fails:
>
> "CURLSOAPTransport failed while contacting SOAP responder:
> error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure"
The IdP web server is probably misconfigured, and is rejecting the certificate without letting the IdP evaluate it.
-- Scott
Ulises Castillo
Can someone please shed some light on the following error message?
opensaml::saml2md::MetadataException: Unable to locate SAML 2.0 identity provider role for provider (urn:mace:incommon:richmond.edu)
Note: We are an SP trying to connect with richmond.edu IdP and the metadata provider is currently set to:
http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml
Thanks and regards,
Ulysses
Learn.com
Mark K. Miller
On Tue, 16 Jun 2009, Mailvaganam, Hari wrote:
> Hi:
>
> Please forward the relevant snippets from the metadata files (IdP & SP)
The metadata files are publicly accessible at the following URLs.
For the IdP, the system name is shoepeg.aset.psu.edu, and its in the
TestShib metadata at:
http://www.testshib.org/metadata/testshib-metadata.xml
For the SP, the system name is springboard.soton.ac.uk, and its in the
UK Federation metadata at:
http://metadata.ukfederation.org.uk/ukfederation-metadata.xml
Thanks!
Scott Cantor
> Hi,
> Can someone please shed some light on the following error message?
Yes, it's not an error. Did it say it was in the log?
> Note: We are an SP trying to connect with richmond.edu IdP and the
> metadata provider is currently set to:
> http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml
InCommon's metadata does not currently include any SAML 2.0-supporting information, only SAML 1.1.
-- Scott
Ulises Castillo
Is it a change in the configuration Shibboleth2.xml or somewhere else?
Mark K. Miller
I'll absolutely agree that the IdP webserver is rejecting the certificate
without letting the IdP evaluate it. Here's the error that apache is
logging:
[Tue Jun 16 10:00:55 2009] [error]
mod_ssl: SSL handshake failed (server shoepeg.aset.psu.edu:8443,
client 152.78.129.14) (OpenSSL library error follows)
[Tue Jun 16 10:00:55 2009] [error]
OpenSSL: error:1408A09F:SSL routines:SSL3_GET_CLIENT_HELLO:length mismatch
So, the certificate obviously never makes it past apache! However, I've
been able to test against other SP with this configuration. So, any
suggestions what could be wrong with my apache config?
Scott Cantor
> So, the certificate obviously never makes it past apache! However, I've
> been able to test against other SP with this configuration. So, any
> suggestions what could be wrong with my apache config?
If you're running with optional_no_ca, then no, I have no idea. What it does
is not in my hands, it's up to libcurl and mod_ssl. Whatever it's doing will
typically be reproducible with s_client or curl directly.
Sometimes there will be a hint on the openssl list about particular
handshake failures, but other than optional_no_ca/validation issues, the
rest is opaque to me, with the exception of that documented
compression-based error message caused by openssl's broken zlib support.
-- Scott
Scott Cantor
> Thank you Scott. You are right, it's a warning, but what is the
> solution to the warning?
The solution is to add SAML 2.0 support to the IdP's metadata (as well as the SP's for that matter). InCommon does not yet allow that, it's coming soon.
-- Scott
Ulises Castillo
-----Original Message-----
From: Scott Cantor [mailto:cant...@osu.edu]
Sent: Tuesday, June 16, 2009 11:10 AM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Unable to locate SAML 2.0 identity provider role for provider
Ulises Castillo
Shibboleth.Listener [1]: dispatching message (defaulthttps://wwws.richmond.edu/shibboleth-idp/SSO::run::SAML2SI)
Then the process ends with:
Shibboleth.Listener [1]: detected socket closure, shutting down worker thread
Could that be related to the same SAM 1.1 vs. SAML 2.0 issue?
Scott Cantor
> OK. The warning is good, but the real issues in my case is that apparently
> Shibboleth stops right there, and there is no redirection to the IdP login
> page or any other message after that. Any suggestion?
Any IdP in the InCommon metadata will have endpoints for SAML 1.x/Shib protocol unless something went wrong with the registration process.
If you changed the SessionInitiator defaults for some reason, change them back.
Turn up the log to DEBUG, if it's creating a request for the client to send, it will show up there.
-- Scott
Scott Cantor
> One added note: Setting the logger is DEBUG mode produced the following
> additional information before the warning:
>
> Shibboleth.Listener [1]: dispatching message
> (defaulthttps://wwws.richmond.edu/shibboleth-idp/SSO::run::SAML2SI)
>
> Then the process ends with: Shibboleth.Listener [1]: detected socket
> closure, shutting down worker thread
>
> Could that be related to the same SAM 1.1 vs. SAML 2.0 issue?
No, it tends to suggest the web server crashed outright, actually. Probably before it got to the next step of falling into the legacy initiator and using SAML 1. If it crashed, the client should be getting an error back in the middle of its request.
-- Scott
Rod Widdowson
> handshake failures, but other than optional_no_ca/validation issues, the
> rest is opaque to me, with the exception of that documented
> compression-based error message caused by openssl's broken zlib support.
It pretty specialized but...
One we have seen is that the needs to push all the intermediate certificates
*if* the IdP is configured to listen to both SOAP and Browser requests on
the same port. This is even if the IdP's Apache has optional_no_ca on for
the SOAP vhost.
Rod
Mark K. Miller
On Tue, 16 Jun 2009, Scott Cantor wrote:
> Mark K. Miller wrote on 2009-06-16:
>> So, the certificate obviously never makes it past apache! However, I've
>> been able to test against other SP with this configuration. So, any
>> suggestions what could be wrong with my apache config?
>
> If you're running with optional_no_ca, then no, I have no idea. What it does
Yup, we're running with optional_no_ca.
> is not in my hands, it's up to libcurl and mod_ssl. Whatever it's doing will
> typically be reproducible with s_client or curl directly.
My "SSL experts" have tried to reproduce this with s_client. If I'm
correct unencrypting everything they're saying; it does not reproduce that
way.
> Sometimes there will be a hint on the openssl list about particular
> handshake failures, but other than optional_no_ca/validation issues, the
> rest is opaque to me,
Just imagine how completely baffled I am by it all!
> with the exception of that documented
> compression-based error message caused by openssl's broken zlib support.
>
> -- Scott
Thank you for all your effort!
Max
Scott Cantor
> My "SSL experts" have tried to reproduce this with s_client. If I'm
> correct unencrypting everything they're saying; it does not reproduce
> that way.
Unless they have access to the same keypair the SP is using, they can't be
reproducing it.
-- Scott
Mark K. Miller
My unencryption has failed me!
I was understanding them to say they were using s_client and 'pointing to'
something at ports on the SP and everything worked ok then. So, you're
saying they were trying to get me to understand something else?
Scott Cantor
IdP or SP? I assume they were pointing to the IdP, but the handshake error
probably includes something to do with client authentication. If they used
some arbitrary keypair to try and negotiate a connection, that would be a
data point. If they didn't include a client certificate in the handshake,
it's not relevant.
Beyond that, you have to try different settings to reproduce the options the
SP uses with libcurl to nail down what's wrong, like switching from SSL3 to
TLS1, that kind of thing.
-- Scott