[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: [Shib-Users] Tomcat SSL Certificate Shibboleth Issue/Question
From:       "Cantor, Scott E." <cantor.2 () osu ! edu>
Date:       2011-06-29 14:30:52
Message-ID: CA30ADD4.EA52%cantor.2 () osu ! edu
[Download RAW message or body]

On 6/29/11 10:22 AM, "Peterson, Tommy" <Tommy.Peterson@xpandcorp.com>
wrote:

>OK. So if everything gets routed through the load balancer (where SSL
>terminates) and I only have a Tomcat 8443 connector for the IDP what
>would using 443 and that certificate do? These people keep telling me
>that since the load balancer is where the SSL terminates that I should
>undo 8443 for the IDP and use port 80. But then I am told that all the
>IDP has to do is import the load balancer's cert. So I am confused as to
>what to do . Would just adding a 443 connector to the Tomcat and using
>this load balancer's cert work here do you think?

The SSL CANNOT terminate there for *SOAP* traffic on the alternate port,
that's what I said.

443 - user facing, commercial cert, can be in the load balancer with the
web server virtualized running on any port or scheme

8443 - SOAP port for attribute queries w/ Shibboleth 1.x SPs, port doesn't
matter, but the cert has to be trusted by partners and the TLS has to
terminate on the web server, not the load balancer

You can virtualize and play games as much as you want, but the TLS
connection for SOAP traffic has to terminate with the web server hosting
the Java container, and the certificate there is what's in the metadata.
That is the one generated by the IdP at install time.

*If* you conclude from requirements that you don't need any SOAP support
(nothing but SAML 2.0 and/or you push attributes with SSO in all cases, no
artifact binding usage, etc.), then you can drop the extra port, do
everything with the load balancer, and the only place the IdP keypair is
used is for signing XML within the IdP, not TLS.

-- Scott


[prev in list] [next in list] [prev in thread] [next in thread]