supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

[Peter Schober]

* anuptiwary <anup.kr.tiwary at gmail.com> [2018-07-27 08:37]:
> *Q.* Why are you using Attribute Queries at all? Is that by design or 
> unintentional? (If the latter: "If it hurts stop doing it.") 
> *AnupTiwary>>* Since it's idp initiated SSO so in response we are expecting
> user header information in the form of attribute.
> or else how to use the same session to redirect it to application dashboard
> instead of login page?

Nothing here has anything to do with attribute queries. The Shib SP
will only perform queries if it does not receive attributes during
SSO. So the fact that you think you have to perform queries just means
your IDP is not configured correctly yet to send this SP any data.

> if I remove below line from shibboleht2.xml, then I am not getting any
> certificate error which is obvious.
> ...
> <AttributeResolver type="Query" subjectMatch="true"/>

Yes, remove that and move on to solving the underlying issue here,
which is the IDP not releasing anything.

> *Q.* If intentional, what's the certificate the IDP presents on port 8443? 
> *AnupTiwary>>*Used the same certificate which was generated while installing
> the idp. (Renewed after configuration as well).

That's not an answer, because the IDP generates several key pairs
during install.

> configured in tomcat using connector port for AJP protocol, since I
> am using httpd as proxy. Below is the tomcat server.xml
> configuration for idp certificate.

Why are you using httpd in front of the IDP? Just because in your
artificial demo setup you have to have httpd for the SP anyway?
(You can run the IDP behind httpd, there's just no good reason to.)

> <Connector SSLEnabled="true"
> SSLImplemention="edu.internet2.middleware.security.tomcat7.DelegateToApplicationJSSEImplementation"
> clientAuth="false" keystoreFile="D:\opt\shibboleth-idp\credentials\idp.jks"
> keystorePass="changeit" maxThreads="150" port="8443"
> protocol="org.apache.coyote.http11.Http11Protocol" scheme="https"
> secure="true" sslProtocol="TLS"/>

What version of the IDP is that? A supported IDP release does not
create an idp.jks, it will generate several key pairs (none by that
name). The one you'd give to Tomcat for the backchannel port is
idp-backchannel.p12.

Creating an IDP and SP on the same machine sounds like a test/demo
setup. But why would you do a demo setup using old (I'm guessing IPD
v2.x), unssupported software?

You don't need a backchannel (hardly anyone does). Even if you needed
can also deploy attribute queries (which you don't need either) using
the normal HTTPS port tcp/443. But let's ignore all that for now.
Your issue is the SP not recieving attributes. Once you fix your IDP
misconfiguration with regards to the backchannel port is irrelevant.

Also, if you're running httpd as web server why would you proxy
tcp/443 through httpd but expose java directly to the network on port
8443? If you proxy why not proxy both the same way?
Then make httpd listen on 8443 and make it use the backchannel key
pair, not Tomcat.

> > *Q.* And all of this is simply a demo setup, since you seem to be
> > running the IDP and the SP all *AT>>* on the same box? Or what
> > else is this for?
> This is POC so that we could move the same approach in actual environment.

It seems to me you're using stale/unsupported software, and normally
there's no need to have an SP co-located on the IDP. And you don't
need httpd installed with Tomcat, unless you know it's needed, which
you don't say, of course.  There's also no need for a backchannel in
most deployments.
So you should not do anything similar in production.

> Please help me out on this, struggling since long at same point. as
> it seems I am almost there but due to lack of knowledge I am not
> able to think in required direction.

No, your setup is a mess, I think. You haven't even identified the
main issue here: Your IDP is not sending any attributes to the SP.
Otherwise the SP wouldn't perform queries.
Once you fix that your IDP will still be misconfigured for queries but
you won't notice it. I think you should still fix that
misconfiguration, but it's easier to just remove port 8443 from your
setup (Tomca Connector or httpd listener) and from your IDP metadata
(also from the copy the SP has).

-peter