bogus ACS URL in authnRequest

[Peter Schober]

We have an ancient install of Confluence 3.0.x (yes, I know about the
"critical" security advisory and that all Confluence versions < 4.2
are vulnerable) with the latest version of the "Shibboleth
Authenticator"/RemoteUser plugin that will run with that version of
Confluence (1.6, IIRC).

Within a Confluence space that's publicly viewable there's a specific
protected page that can only be accessed successfully if there is a
pre-existing Confluence (and/or Shib) session, but when accessed
without a session (i.e., requires generation of an authnRequest and
roundtrip to the IdP) generates a bogus ACS URL in the AuthnRequest to
the IdP, which then (correctly) fails with a "No peer endpoint
available to which to send SAML response" error message.

Here's the ACS URL from the SP's shibd.log on DEBUG. The only editing
done (except for line breaks) was replacing the (short) hostname
(as in `hostname -s`) of the SP and IdP with 'sp' and 'idp':

2012-06-03 17:13:34 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1709]: marshalled message:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://sp.univie.ac.athttps:/Shibboleth.sso/SAML2/POST"
Destination="https://idp.univie.ac.at/idp/profile/SAML2/Redirect/SSO"
ID="_e6af61ef50ba87878be36734fe182c76" IssueInstant="2012-06-03T15:13:34Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.univie.ac.at/shibboleth</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="1"/>
</samlp:AuthnRequest>

Httpd is configured properly with
  ServerName https://wiki.univie.ac.at:443
  UseCanonicalName On
and speaks to the servlet container (Apache Tomcat 6) via AJP
(and ApplicationDefaults/@attributePrefix="AJP_" in shibboleth2.xml).

The webserver is RHEL5.8's httpd 2.2.3, the SP is current (2.4.3),
using the "new" shortened config with the default relative handlerURL
(and showed the same behaviour with the old config format, so this is
jfyi).

Any ideas where the spurious 'https:' after the hostname and before
the handerURL might come from?

cheers,
-peter