Secure Proxy Server 12.52 - Virtual Host Configurations

[Chris Bertagnolli]

Fairly new to the proxy world and had some questions on the SPS specifically.

 

Basically, trying to determine specific SPS requirements for the following needs:

 

- SPS is fronted with a user-facing load balancer VIP configs (let's say the following apps: order.domain.com, register.domain.com, search.domain.net)

- SPS server to have only one IP address assigned

- Multiple virtual hosts  (hosts: order.domain.com, register.domain.com, search.domain.net)

- All virtual hosts protected with SSL

 

One of the statements in the SPS guide mentions that a limitation with SSL is that "

Apache virtual hosts using the SSL protocol:

• Must be IP-based due to limitations in the protocol.

 

However, Apache, with SNI can do host based + SSL (SANS cert and what not if necessary).

 

So question time:

 

- Is it true that each virtual host needs to have a unique IP address assigned to each SPS? Or is there a way to configure multiple hosts / proxy rules using a single IP (e.g., <virtual host  *:443>) ?

- If not true, do we just set it up with normal Apache virtual host configs using host names? Or are there specific SPS settings that need to be setup?

- Finally, can the SPS forward a request on one port to another for the same requested host? Basically the logic being "IF order.domain.com:443 THEN forward to order.domain.com:8443"

 

The real sticking point for our implementing this was the statement in the guide, which, at least to us, read as though we'd need TONS of IP addresses. There's potentially dozens or more Virtual Hosts that would be going through the Secure Proxy Server - and of course that would lead to way more IP addresses than we'd ever want to deal with .

[Karmeng]

Hi,

I'm new to SPS as well. I'm kind of interested to know the answers of the questions. Let me tag a SPS guru Mark.ODonohue
I believe what mentioned in guide is correct and maybe we can have a workaround to fix the issue.

[Chris Bertagnolli]

Thanks . 

 

I sure hope it is wrong, from what I understand of other proxies that have been setup that are not using CA SPS a separate IP is not necessary; they all use host based and single IP address and working fine with SSL. IF it's true that CA product needs a separate IP address for each host name that will use SSL, that's a really bad design flaw then when looking at a broad scaled deployment with multiple SPS instances and numerous virtual hosts.

[Mark ODonohue]

SPS front end is just Apache - so the answer for SPS is the same as Apache setup.

 

The virtual host setup in server.conf is fairly well described in another post here, and is independent of if the request arrived via HTTP or HTTPS to front end of Apache.

 

The tricky part is setting up SSL for multiple hosts in the frontend Apache/SPS.

 

There is a bit of a chicken-and-egg thing going on with host names in SSL.  Since the client wont sent the Host: header to the server until it has a secure SSL channel open, and to open an SSL connection the Apache/SPS Webserver needs to send the client an SSL certificate with common name that matches the host name that the client hasnt sent yet.

So for SSL setup in SPS/Apache the solutions fall into the following categories:

 

• Listening on one IP - with one virtual host name.
  If you have one virtual host name, then it is an easy setup, with SPS listening on port 443 you have one X.509 server cert with CN=www.example.com , and you send that cert for any request.

 

• Listening on multiple IP addresses - with multiple virtual host names
  If you wanted to have SPS listening on SSL for multiple virtual hosts, then the original Apache way was to have each virtual host listening on a different IP address (or port) and you could configure a different X.509 cert for each IP address or port.  That way when client request arrives at 192.168.1.10  you "knew" it was for www.example.com, and so you sent the right certificate.  If arrives on 192.168.1.11 you "know" it is for ws.example.com and so you send a different certificate, one with CN=ws.example.com.
  
  
• Listening on one IP - with multiple virtual host names (altname & wildcard certs).
  Obviously if you have many virtual hosts, such as a IP service provider would do, then its a problem, since you dont really want to have a new IP address for each new virtual host. 
  The first answer is X.509 certs which allow multiple subject DNS names, and the second answer is Wildcard certs CN=*.example.com.  With these X.509 certs the setup is similar to having a single certificate, you can safely listen on one :443 port, and send your special Altname or Wildcard cert for any request on that IP/port.   The client will then accept that cert for all the altnames, or any virtual host name that fits within the wildcard match, and then after the HTTPS/SSL stream is negotiated it send you the HTTP request with the internal Host:www.example.com header.  The Host; header is then passed via mod_jk onto the proxy-engine, where it (hopefully) matches one you have in server.conf virtual hosts settings.

For more about Altname and Wildcard certs, wikipedia is a good place to start.

 

http://en.wikipedia.org/wiki/SubjectAltName

http://en.wikipedia.org/wiki/Wildcard_certificate

 

Cheers - Mark

 

PS: And thanks Kar Meng for tagging me.

[Mark ODonohue]

Just to follow up on this, in the above I didnt cover the SNI setting :

As you mention :    
     However, Apache, with SNI can do host based + SSL (SANS cert and what not if necessary).

 

And a lot of browsers now support this, where they send the hostname in the SSL ClientHello message,  Apache can then pick the right cert to do the handshake - And Apache (the one in SPS) does support this - although that is part of the apache doco not in the SPS specific doco

 

Cheers - Mark

[Chris Bertagnolli]

Well, it works in a DEV environment somewhat. Using hostname based virtual host we're able to do different proxy rules. Not sure why the docs say you must use a unique IP...?

 

The only problem seems to be using separate ACOs. For some reason when attempting to use different ACOs for the different virtual hosts (when not using unique IP addresses for each) has not been going so well, throws start up errors. The hosts which use their own IP address don't have the problem. Probably just some configuration we got messed up...at least hoping.

[Karmeng]

Hi,

Glad it works in DEV environment but I'm still have no answer for first 2 questions.

 

As for third question, I think you can try following in proxyrules.xml,

 

<nete:case value="order.ca.com:443">

   <nete:forward>http://order.ca.com:8443$0</nete:forward>

  </nete:case>

[Legacy User]

It's been a while now. However pulled this out from a very old config backup. I know that a single IP works even if were to add multiple VH in Server.conf. This is something that I have tested on both using SSL and nonSSL modes on the same SPS.

 

 

Proxy Rules with hostheaders.

 

 

[root@spsproxy-test1 ~]# more /ProgramFiles/CA/Agent-for-SharePoint/proxy-engine/conf/proxyrules.xml

<?xml version="1.0"?>

<?cocoon-process type="xslt"?>

<!DOCTYPE nete:proxyrules SYSTEM "file:////ProgramFiles/CA/Agent-for-SharePoint/proxy-engine/conf/dtd/proxyrules.

dtd">

 

 

<!-- Proxy Rules-->

<nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">

<nete:cond type="host" criteria="equals">

        <nete:case value="sp1.spsproxy-test1.sps.com:80">

                <nete:forward>http://sharepointmac1:2000$1</nete:forward>

        </nete:case>

        <nete:case value="sp1.spsproxy-test1.sps.com:443">

                <nete:forward>http://sharepointmac1:2000$1</nete:forward>

        </nete:case>

        <nete:case value="sp2.spsproxy-test1.sps.com:80">

                <nete:forward>http://sharepointmac2:1000$1</nete:forward>

        </nete:case>

        <nete:case value="sp2.spsproxy-test1.sps.com:443">

                <nete:forward>http://sharepointmac2:1000$1</nete:forward>

        </nete:case>

        <nete:case value="sp.spsproxy-test1.sps.com:80">

                <nete:forward>http://sharepointmac1:1000$1</nete:forward>

        </nete:case>

        <nete:case value="sp.spsproxy-test1.sps.com:443">

                <nete:forward>http://sharepointmac1:1000$1</nete:forward>

        </nete:case>

        <nete:case value="sp3.spsproxy-test1.sps.com:80">

                <nete:forward>http://sharepointmac2:2000$1</nete:forward>

        </nete:case>

        <nete:case value="sp3.spsproxy-test1.sps.com:443">

                <nete:forward>http://sharepointmac2:2000$1</nete:forward>

        </nete:case>

        <nete:case value="sp4.spsproxy-test1.sps.com:80">

                <nete:forward>http://sharepointmac2:3000$1</nete:forward>

        </nete:case>

        <nete:case value="sp4.spsproxy-test1.sps.com:443">

                <nete:forward>http://sharepointmac2:3000$1</nete:forward>

        </nete:case>

        <nete:case value="sp5.spsproxy-test1.sps.com:80">

                <nete:forward>http://sharepointmac2:40001$1</nete:forward>

        </nete:case>

        <nete:case value="sp5.spsproxy-test1.sps.com:443">

                <nete:forward>http://sharepointmac2:40001$1</nete:forward>

        </nete:case>

 

 

        <nete:default>

                <nete:forward>http://www.aol.com$0</nete:forward>

        </nete:default>

</nete:cond>

</nete:proxyrules>

 

 

 

 

Regarding using different ACO, it is possible if we have multiple WebAgent.conf. See below. However remember to make sure that SERVERPATH in WebAgent.conf is unique for each VH. This is same thumb rule if we follow if we had a single apache install, however wanted to run multiple apache instances using different configuration files.

 

 

SERVER.CONF

 

<VirtualHostDefaults>

  # default session scheme

  defaultsessionscheme="default"

  enablerewritecookiepath="no"

  enablerewritecookiedomain="no"

  enableproxypreservehost="no"

 

  policyserverversion=12.5

 

 

  # specify the block size for request and response in KBs

  requestblocksize="4"

  responseblocksize="4"

 

 

  #TO-DO:  Define any session scheme mappings

  #<SessionSchemeMappings>

  #    user_agent_name=session_scheme_name

  #</SessionSchemeMappings>

 

 

  # Web Agent.conf

  <WebAgent>

  # sminitfile="C:\Program Files\CA\Agent-for-SharePoint\proxy-engine\conf\defaultagent\WebAgent.conf"

  </WebAgent>

 

 

</VirtualHostDefaults>

 

 

# Default Virtual Host

<VirtualHost name="default">

  #addresses="192.168.1.100"

  hostnames="spagent1.ca.com"

  defaultsessionscheme="default"

 

  # specify the block size for request and response in KBs

  requestblocksize="4"

  responseblocksize="8"

 

 

  #The defaults can be overriden

  #not only for the Virtual Host

  #but for the WebAgent for that

  #virtual host as well

  #<WebAgent>

sminitfile="C:\Program Files\CA\Agent-for-SharePoint\proxy-engine\conf\defaultagent\WebAgent1.conf"

  #</WebAgent>

</VirtualHost>

 

 

# Default Virtual Host

<VirtualHost name="sp">

  #addresses="192.168.1.100"

  hostnames="sp.ca.com"

  defaultsessionscheme="default"

 

  # specify the block size for request and response in KBs

  requestblocksize="4"

  responseblocksize="8"

 

 

  #The defaults can be overriden

  #not only for the Virtual Host

  #but for the WebAgent for that

  #virtual host as well

  #<WebAgent>

sminitfile="C:\Program Files\CA\Agent-for-SharePoint\proxy-engine\conf\defaultagent\WebAgent2.conf"

  #</WebAgent>

</VirtualHost>

 

 

 

 

WEBAGENT CONF

 

# WebAgent.conf - configuration file for SiteMinder Secure Proxy

# Secure Proxy Version = , Build = 131, Update = 0000

 

 

LOCALE=en-US

 

 

HostConfigFile="C:\Program Files\CA\Agent-for-SharePoint\proxy-engine\conf\defaultagent\SmHost.conf"

AgentConfigObject="wac_spagent2010"

ServerPath="ServerPath_"

EnableWebAgent="YES"

localconfigfile="C:\Program Files\CA\Agent-for-SharePoint\proxy-engine\conf\defaultagent\LocalConfig.conf"

LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\HttpPlugin.dll"

LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\SPSPlugin.dll"

LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\SPPlugin.dll"

LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\DisambiguatePlugin.dll"

#LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\OpenIDPlugin.dll"

#LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\SessionLinkerPlugin.dll"

#LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\OAuthPlugin.dll"

#LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\SAMLDataPlugin.dll"

#LoadPlugin="C:\Program Files\CA\Agent-for-SharePoint\agentframework\bin\CertSessionLinkerPlugin.dll"

AgentIdFile="C:\Program Files\CA\Agent-for-SharePoint\proxy-engine\conf\defaultagent\AgentId.dat"

 

 

 

 

ADDITIONAL INFO: You'd need to consider.

 

Start SPS in Single or Multi Process Mode

SPS supports single-process and multiple-process modes, which enable the embedded Web Agent to create the Low Level Agent Worker Process (LLAWP) at runtime.

SPS can be configured to start in a single-process or multiple-process mode. Single-process mode is the default.

The modes operate as follows:

Single-Process Mode

This mode causes the Web Agent to use local resources rather than shared operating system resources offered by the LLAWP to operate. No separate LLAWP processes are started in single-process mode. When multiple virtual hosts run, single-process mode results in an increase in the memory footprint of the SPS Java process.

Note: Single-process mode is supported only for host servers that run as a single server process.

Multiple-Process Mode

This mode causes the LLAWP framework to spawn a process for every virtual host. Because multiple-process mode uses shared memory, SPS uses shared operating system resources for logging, caching, and monitoring of multiple web server processes.

To set the mode of operation

1. Open the server.conf file in a text editor.
2. Set the singleprocessmode parameter as follows:
   • To use single process mode, keep singleprocessmode set to yes.
   • To use multiple-process mode, change singleprocessmode to no.
3. If you modify the server.conf file, restart SPS.

The SPS mode of operation is set.

[Chris Bertagnolli]

Thanks all for the great information. Makes things much more clear in terms of configuration options. I think the documentation wording perhaps needs to be tweaked to avoid confusion over IP requirement.

 

We are proceeding with a configuration with the single IP address, multiple virtual hosts (and virtual hosts with multiple hostnames) and a SANS cert. Apache has no problems with it (as expected) and the SPS is proxying the traffic properly by the host name. The forwarding a request on port A to the same FQDN on port B also appears to be ok; helps reduce additional VIP requirements for load balancing the application servers versus the user-facing front-end load balanced proxies. Promising setup so far.

 

Now if the SPS SP1 upgrade would just go smoothly

[Chris Bertagnolli]

Just a quick update. Everything seems ok until a load balancer is put in front. Once that is done, the SPS stops processing requests for a virtual host when no IP is explicitly defined.

 

Will be looking into that. The current configuration has virtual hosts created in the GUI with no IP defined. Then the Apache httpd-ssl.conf has the virtual hosts all configured for single IP address. This works just dandy when going directly to the server, but pulling a load balancer into the front-end it starts failing; not clear where the issue is (LB or SPS) at the moment.

 

If an IP is explicitly defined in the virtual host through the GUI, then it works just fine.

[RaviSapare]

Hi Bert,

 

Mutliple Virtual Host with Load Balancer worked? If you have any info please update here that would be helpful for us.

 

Thanks,

Ravi

[Chris Bertagnolli]

We never got it working properly. Ultimately we basically abandoned the SPS cause it is so buggy, got slammed with security risks all the time (outdated OpenSSL / HTTPD / Tomcat etc), and not very stable; using a standard Apache + Web Agent is much better for what we needed and allows us to stay mostly up to date on everything but still get a proxy.

[Legacy User]

Hi Bert,

 

Can you share the httpd-ssl.conf and httpd.conf files that you had configured.

 

Thanks,

Chris