Apache 2.x POST Bug
A known bug in Apache 2.x (not present in 1.3.x) can prevent the POST requests used by Shibboleth from working if "SSLVerifyClient optional" or "SSLVerifyClient required" is placed within a <Location> container, overriding a global "SSLVerifyClient none".
Because this construction is needed if the Shibboleth attribute authority and handle server are in the same context, the conventional workround is to put the Apache <Location> directives for the Shibboleth attribute authority and handle server into separate virtual hosts (vhosts). However:
- Apache can only decrypt presented URLs after an initial SSL protocol handshake.
- Since the SSL handshake depends on configuration settings that can differ between vhosts, named virtual hosts (distinguished by URL path) cannot be used with SSL.
- The only other way to distinguish vhosts is to use different port numbers or IP addresses.
Using different port numbers is simplest and is the emerging convention. For example:
Only one certificate (for shibbox.uni.ac.uk) is required in this case.
However, with a single IP address only one of the handle server or attribute authority can have the standard SSL port number (443). An agent behind a firewall that filters outgoing traffic may find the other port blocked. For the HS, the agent is the end user's browser; for the AA it is a Shibboleth target. Giving the standard port number to the HS avoids imposing firewall constraints on end users. It still leaves a potential problem for targets though. If this is likely to be an issue for your users' intended targets then different IP addresses may be required for the two vhosts:
- These IP addresses must then be given distinct DNS names (e.g., hs.uni.ac.uk and aa.uni.ac.uk). Note that assigning IP addresses and domain names will require liason with your network administrators.
- Because the Common Name in an SSL server certificate must match the server's DNS name, two certificates are now needed for the origin, one for each DNS name.
The status of the Apache 2.x bug described above can be tracked at:
The simpler workround discussed there, of setting "SSLClientVerify optional" globally, is of limited use with Shibboleth, because it will make the handle server request a client certificate from the end user. The effect with Internet Explorer is that a dialog box appears asking the user to choose from a list of suitable client certificates, which will usually be empty. Hitting Escape to proceed with no certificate may be acceptable during initial testing but could cause confusion in production use.