Mucking about with Shibboleth again, and ran into some errors on the SP, specifically:
2007-07-10 19:49:42 DEBUG SAML.libcurl  sessionGet: SSL read: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate, errno 0
This is the “catch-all” error message for Shibboleth OpenSSL Errors. After much research and testing, it was a problem with the IdP, their server was rejecting my client certificate.
How it should work (I think)
- User requests protected content on the SP
- SP redirects to the IdP for authentication
- IdP authenticates user, sends an SSL (with client certificae) SOAP request to the SP with some info, and then redirects the user back
- SP validates SOAP request by comparing client certifacte with a white-list in the shibboleth metadata
- SP sends an SSL (with client certificate) SOAP request to IdP to get more information about the user (in my case, a username so I can identify them in my database)
- IdP validates SSL cert of SP with a white-list in their shibboleth metadata, responds with whatever information was requested
- SP uses that information to serve or deny access to the user from step 1
Be sure the SP recognizes the IdP’s certs
First up, check that the SP has the IdP’s certs in order:
openssl s_client -connect HOST:443 -showcerts
That will give you back the certificate chain:
0 s: SUBJECT FOR THE IDP
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
subject=SUBJECT FOR THE IDP
some other stuff…
The issuing certificate (in the example, cert 1) should be in your shibboleth metadata. All you need is the top-most issuer, and shibboleth will look down the certificat chain until it finds a certificate it trusts, and all will be well.
If that doesn’t solve it, then we see if the IdP has the SP cert straight.
Be sure the IdP recognizes the SP’s certs
This is harder to debug from the SP’s side, but you can try make an SSL connection using the SP cert and key:
openssl s_client -connect HOST:443 -showcerts -cert SP.crt -key SP.key
If that connects, then you know the server isn’t rejecting you outright, but it’s possible that Apache config is rejecting you elsewhere. The best way to check is to just ask your IdP if your config is still in their shibboleth white-list.
If that doesn’t solve it, check the apache config.
Be sure everyone’s apache config is OK
The possible failure here is that the certificate is being rejected before making it to shibboleth. You don’t want to tell your whole server to accept any client certificate, you want to just pass those through to shibboleth and let shibboleth decide. You’ll want to have
SSLVerifyClient optional_no_ca in your Apache location blocks for shibboleth URLs.
Certificates are a good idea, but a pain in the ass. The shibboleth-users mailing list is a good source of information, and you can get prompt replies from there. And next time I have this problem, I’ll know where to look for debugging tips.