Multi-Domain SP

[Simon Bright]

Hi Ran 

Just jumping in here. We have two vhost set up here on Apache. I'll refrain from saying "you must have" but you may find that it will only work if you have separate IP for each host. 

My ssl.conf file has these lines. My server has two IP addresses on 1 nic. The following config is then duplicated for each host , using the correct IP address hostnames and certificate paths for each. 

<VirtualHost [ip address here]:443> 
ServerName hostname:443 
DocumentRoot /var/www/html/hostname 
ErrorLog logs/hostname/ssl_error_log 
TransferLog logs/hostname/ssl_access_log 
LogLevel warn 
SSLEngine on 
SSLVerifyDepth 10 
SSLOptions +StdEnvVars +ExportCertData 
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW 
SSLCertificateFile /path-to-certificate 
SSLCertificateKeyFile /path-to-key 
SSLCertificateChainFile / path-to-cabundle 
SSLVerifyClient none 
</VirtualHost> 



Regards 

Simon Bright 
Technical Services Manager 
E2BN 
01462 834588 
07912 853 107 
www.e2bn.org 



----- Original Message -----

Well after a few days of playing around with this, I literally narrowed down the problem to 3 lines in server.conf. 

This is my current configuration: 



    1. ServerName https://original.example.com:443 
    2. UseCanonicalName On 
    3. ProxyPreserveHost On 
    4. ProxyIOBufferSize 65536 
    5. <VirtualHost new-host.example.com:443 > 
    6. ServerName https://new-host.example.com:443 
    7. UseCanonicalName On 
    8. <Location /> 
    9. </Location> 
    10. </VirtualHost> 

With this configuration, original is able to login and new-host gives the error. 

If I change line #5 to: 
<VirtualHost new-host.example.com:*> 
The situation is reversed and new-host logins, while new-host gives the error. 

What is wrong with my binding?? I've tried every combination I can think of but nothing works. 




On Mon, Mar 11, 2013 at 2:31 PM, Ran < ran at sheinberg.net > wrote: 



It's not working yet, no. the error did not change. 
opensaml::BindingException at ( https://original.example.com/Shibboleth.sso/SAML2/POST ) 
SAML message delivered with POST to incorrect server URL. 

I understand your comment about the VirtualHost directive. in that case, this is what I have right now: 

<VirtualHost new-host.example.com:443 > 
ServerName https://new-host.example.com:443 
<Location /> 
AuthType shibboleth 
require shibboleth 
ShibUseHeaders on 
</Location> 
</VirtualHost> 

The ServerName in the VirtualHost is correct, because I can paste it in my browser and get to the Apache landing page. this is what I'm using to build the Request URL. 
Am I missing any directives in that snippet? at this point I'm just winging it by copying different parts from different guides. 


On Mon, Mar 11, 2013 at 2:23 PM, Peter Schober < peter.schober at univie.ac.at > wrote: 

<blockquote>
* Ran < ran at sheinberg.net > [2013-03-11 13:11]: 
> Well I removed all the irrelevant stuff per your recommendation. 
> Removed all the added stuff from Shibboleth.xml 
> Started fresh on the IdP by regenerating the Metadata from the SP and 
> adding the ACS URLs + upped their indexes. 

Didn't see an error report in your mail, though, so is it working as 
expected? 

> Now I think the last point is httpd.conf. this is what I left: 
> <VirtualHost new-host.example.com:443 > 
> ServerName new-host.examplecom:443 
> ServerAlias new-host.examplecom 
> UseCanonicalName On 
> </VirtualHost> 
> 
> I am trying without Location and the applicationId as you mentioned. 
> am I using the directives correctly? 
> And another question is how should the Virtualhost do the binding? on port 
> 443 which is what the Load Balancer is listening on? or maybe 8080 since 
> this is what the Application is listening to (so maybe <VirtualHost 
> new-host.example.com:8080 > ? that doesn't seem to work as well... 

So you are in fact terminating SSL at some other system? The advice 
stays the same: ServerName needs to be correct. Correct means matches 
whatever the HTTP User Agent sees, i.e. including the schema (https) 
before the hostname. 
On what local TCP port you have your httpd listen is irrelevant for 
any purposes of this list and the Shibboleth software (assuming you 
don't intend on exposing this to the network). What's wrong with port 
80? But local deployment choice, really. 
Also note that httpd does not bind to ports based on virtualhost 
directives (it uses the Listen directives for that). 
-peter 
-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net 





</blockquote>



-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130311/c43c395d/attachment.html