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

[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