Help with error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown

[Coeus[TM]]

Hi,

I am having a problem with the SP (we provide service to different
federations/Idps)
encountering the exception as posted below (the lines posted are
specific for an Idp
only):

2012-02-13 05:36:30 DEBUG XMLTooling.SOAPTransport.CURL [2]: sending
SOAP message to
https://idp.sample.net:8443/idp/profile/SAML1/SOAP/AttributeQuery
2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: About to connect()
to idp.sample.net port 8443

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: Trying 117.777.777.77...
2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: connected

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: Connected to
idp.sample.net (117.777.777.77) port 8443

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: successfully set
certificate verify locations:

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: CAfile:
/etc/pki/tls/certs/ca-bundle.crt
CApath: none

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, Client hello (1):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, Server hello (2):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, CERT (11):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]:
2012-02-13 05:36:30 DEBUG XMLTooling.SOAPTransport.CURL [2]: invoking
custom X.509 verify callback
2012-02-13 05:36:30 DEBUG XMLTooling.TrustEngine.ExplicitKey [2]:
attempting to match credentials from peer with end-entity certificate
2012-02-13 05:36:30 DEBUG XMLTooling.TrustEngine.ExplicitKey [2]:
end-entity certificate matches peer RSA key information
2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, Server key exchange (12):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]:
2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, Request CERT (13):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]:
2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, Server finished (14):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, CERT (11):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]:
2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, Client key exchange (16):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, CERT verify (15):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS change
cipher, Client hello (1):

2012-02-13 05:36:30 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS
handshake, Finished (20):

2012-02-13 05:36:31 DEBUG XMLTooling.libcurl [2]: SSLv3, TLS alert,
Server hello (2):

2012-02-13 05:36:31 DEBUG XMLTooling.libcurl [2]: error:14094416:SSL
routines:SSL3_READ_BYTES:sslv3 alert certificate unknown

2012-02-13 05:36:31 DEBUG XMLTooling.libcurl [2]: Closing connection #0

2012-02-13 05:36:31 ERROR Shibboleth.AttributeResolver.Query [2]:
exception during SAML query to
https://idp.sample.net:8443/idp/profile/SAML1/SOAP/AttributeQuery:
CURLSOAPTransport failed while contacting SOAP responder:
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate
unknown
2012-02-13 05:36:31 ERROR Shibboleth.AttributeResolver.Query [2]:
unable to obtain a SAML response from attribute authority

I have already read through the mailing list regarding the
"error:14094416..." Based from the discussions,
it all boils down to where Idp rejects SP's certificate (mod_ssl issues, etc..).

But one thing that is different in my case is that the Idp people told
me that they have already set SSLInsecureRenegotiation
and SSLVerifyClient to "optional_no_ca". They also included our
metadata. I am also sure
that I have the right key pairs and included their metadata in
wayfconfig.xml and shibboleth2.xml. I have another
federation/Idps to test to so I know that I still have the correct SP
configurations. Unfortunately, with all these applied,
I am still encountering the exception and I believe this is the reason
why a user (after logging in to the Idp auth site)
cannot successfully log in to the next SP page (the user is properly
directed to the page but prompts that the user
is not yet authorized to use the service and may contact customer services).

Hopefully someone here has any other idea why the Idp is not
responding from our SP's query. Would it be possible
also that the Idp has logs to refer to and confirm that we (SP) are
sending the X509Certificate correctly? Or any ideas
that you may have to troubleshoot the problem as I am already
frustrated for a week.

Your help is greatly appreciated.

Thank you.

ps:

* Idp's login page uses a self-generated certificate. In my browser, it says:
The security certificate presented by this website was not issued by a
trusted certificate authority.
The security certificate presented by this website was issued for a
different website's address.
I am assuming that this is normal and I can continue to their login page anyway.

* The Idp does not have any federation yet so I also added their
federation in the
discovery page - both of them are new.
--
To unsubscribe from this list send an email to users-un...@shibboleth.net

[Cantor, Scott]

>
>I have already read through the mailing list regarding the
>"error:14094416..." Based from the discussions,
>it all boils down to where Idp rejects SP's certificate (mod_ssl issues,
>etc..).

Yep.

>But one thing that is different in my case is that the Idp people told
>me that they have already set SSLInsecureRenegotiation
>and SSLVerifyClient to "optional_no_ca".

That may be, but there are other reasons mod_ssl will break (expired certs
that are self-signed, chain depth issues, others) and reject the
certificate, and there are also plenty of cases where people will swear up
and down it's set to that and it turns out not to be.

One test is to not use a certificate at all and see if Apache will let the
request past to the IdP and get rejected there. If the Apache server
refuses to accept a request with no certificate, then it can't be set up
in that fashion.

> They also included our
>metadata. I am also sure
>that I have the right key pairs

mod_ssl has no idea what metadata is. If Apache steps in, you're dead. The
whole point is to get past it. Which is why we no longer suggest using it
when possible.

>Hopefully someone here has any other idea why the Idp is not
>responding from our SP's query. Would it be possible
>also that the Idp has logs to refer to and confirm that we (SP) are
>sending the X509Certificate correctly?

The IdP isn't even running your request.

> Or any ideas
>that you may have to troubleshoot the problem as I am already
>frustrated for a week.

It's not within your capability to fix unless you're prepared to change
the certificate used to meet the requirements of the IdP. Using the IdP
with SOAP requires that the deployer support non-validation by the web
server. When you violate that constraint, you have a broken IdP. We have
filed the bugs needed to get Apache to fix this. They refuse. So we're
stuck. The answer we have is, don't use Apache in front of the IdP, or at
least not in front of the SOAP port. Often it's viable to use Apache on
443 and go direct on 8443. Or, of course, don't use SOAP.

Or one can use signing instead of TLS. That has security implications that
we're not prepared to walk people through and that's why we don't
emphasize it. But it is a way around the issue.

-- Scott

[Coeus[TM]]

Thank you for the prompt response.

>One test is to not use a certificate at all and see if Apache will let the
>request past to the IdP and get rejected there. If the Apache server
>refuses to accept a request with no certificate, then it can't be set up
>in that fashion.

"to not use a certificate", do you mean leaving the <X509Certificate>
value to empty for both SP and Idp metadata?

>mod_ssl has no idea what metadata is. If Apache steps in, you're dead. The
>whole point is to get past it. Which is why we no longer suggest using it
>when possible.

Just wondering about what they (Idp) said that they do not have any
issues or problems
with their other SPs aside from our SP.

[Cantor, Scott]

>
>"to not use a certificate", do you mean leaving the <X509Certificate>
>value to empty for both SP and Idp metadata?

No, I mean initiating a TLS handshake with openssl or some other client
tool with no client cert. This is a low level problem. There are no high
level solutions or steps. It's dirty and highly technical.

>Just wondering about what they (Idp) said that they do not have any
>issues or problems with their other SPs aside from our SP.

Not using SOAP at all, or not encountering whatever mod_ssl error
condition is triggered by this certificate. They could be imposing
certificate constraints on every other SP and just sticking a CA into the
root list. Unless they're supporting existing self-signed certs on those
SPs, it isn't even worth asking.

They also have logs. What do they say? mod_ssl often logs specifics when
it rejects a cert.

-- Scott

[Coeus[TM]]

Already asked for their mod_ssl.log. Going to post it once they sent it.

I only have the snippet below from their shibd.log

11:21:25.297 - INFO [Shibboleth-Access:73] -
20120203T055125Z|101.11.111.1|fooidp.net:443|/profile/Shibboleth/SSO|
11:21:27.318 - INFO
[edu.internet2.middleware.shibboleth.common.security.MetadataPKIXValidationInformationResolver:802]
- PKIX validation info cache cleared
11:21:27.318 - INFO
[edu.internet2.middleware.shibboleth.common.security.MetadataPKIXValidationInformationResolver:802]
- PKIX validation info cache cleared
11:21:41.577 - INFO [Shibboleth-Access:73] -
20120203T055141Z|101.11.111.1|fooidp.net:443|/profile/Shibboleth/SSO|
11:21:41.610 - INFO [Shibboleth-Audit:714] -
20120203T055141Z|urn:mace:shibboleth:1.0:profiles:AuthnRequest||https://foosp.net/shibboleth-sp|urn:mace:shibboleth:2.0:profiles:saml1:sso|https://fooidp.net/idp/shibboleth|urn:oasis:names:tc:SAML:1.0:profiles:browser-post|_m68dgh663f6263e8741d816fe8ca742z|foo...@foouser.org|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||_77774ded31fcca7777d448625eb17777|_77777e6be1c2eeb77777a90ffd977777,|

They also advised me to read the link below and suggested to apply the
workarounds (OpenSSL re-enable "unsafe" or upgrade or downgrade
version):
https://wiki.shibboleth.net/confluence/display/SHIB2/SSL+Renegotiation

This would be my last option.

[Cantor, Scott]

On 2/14/12 9:10 PM, "Coeus[TM]" <coeu...@gmail.com> wrote:
>
>I only have the snippet below from their shibd.log

That's an IdP log, and there's nothing the IdP can do about mod_ssl. There
can be nothing in it by definition.

>They also advised me to read the link below and suggested to apply the
>workarounds (OpenSSL re-enable "unsafe" or upgrade or downgrade
>version):
>https://wiki.shibboleth.net/confluence/display/SHIB2/SSL+Renegotiation

That causes timeouts, not certificate rejection.

If they won't fix their IdP, then your only choice is to live with their
restrictions on certificates and change what you're using, or switch to
message signing.

-- Scott

[Coeus[TM]]

Hi,

It has been a while since the last activity for this topic.
Unfortunately, they have not provided me a snippet from their
logs.

But recently I also tested integrating another Idp which ended up
in a similar case.

Now, I am suspecting that from these lines below:

(from the previously reported):
2012-02-17 06:38:55 ERROR Shibboleth.AttributeResolver.Query [27]:

exception during SAML query to

https://idp-host1:8443/idp/profile/SAML1/SOAP/AttributeQuery:

CURLSOAPTransport failed while contacting SOAP responder:
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate
unknown

(new Idp under testing):
2012-03-13 06:54:49 ERROR Shibboleth.AttributeResolver.Query [1]:

exception during SAML query to

https://idp-host2:8443/idp/profile/SAML1/SOAP/AttributeQuery:

CURLSOAPTransport failed while contacting SOAP responder:

error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected
message

I am running a Shibboleth SP ver. 2.1.0 but tries to connect to a SAML
1 endpoint where I believe these 2 different Idp's already defined an
SAML 2 endpoint in their metadata.

What should I need to reconfigure so that the SP will connect to the
SAML 2 endpoint?

Thanks!

[Cantor, Scott]

> I am running a Shibboleth SP ver. 2.1.0 but tries to connect to a SAML
> 1 endpoint where I believe these 2 different Idp's already defined an
> SAML 2 endpoint in their metadata.

But the SSO protocol used is SAML 1, and that means the query will be too.

> What should I need to reconfigure so that the SP will connect to the
> SAML 2 endpoint?

No idea, depends how your invoking things. If you're using a legacy WAYF, you can't. If there's a DS or you're doing something else, it should automatically select SAML 2 if that's earlier in the list of protocols or SessionInitiators.

And lastly, you'd better not be using SP V2.1, because that is vulnerable to attack.