It appears that the core of my problem was that I was unaware of

Option HttpsHyphens / NoHttpsHyphens

which toggle between proxying on

https://www.somedb.com.ezproxy.yourlib.org

and

https://www-somedb-com.ezproxy.yourlib.org

and allows infinitely nested domains to be proxied using a simple
wildcard cert by compressing things.

The paranoid in me is screaming that there's an interesting brokenness
in here when a separate hosted resource is at https://www-somedb.com/,
but I'm trying to overlook that.

cheers
stuart
--
...let us be heard from red core to black sky


On Mon, Dec 15, 2014 at 9:24 AM, Stuart A. Yeates <[log in to unmask]> wrote:
> Some resources are only available only via HTTPS. Previously we used a
> wildcard certificate, I can't swear that it was ever tested as
> working, but we weren't getting any complaints.
>
> Recently browser security has been tightened and RFC 6125 has appeared
> and been implemented and proxing of https resources with a naive
> wildcard cert no longer works (we're getting complaints and are able
> to duplicate the issues).
>
> At https://security.stackexchange.com/questions/10538/what-certificates-are-needed-for-multi-level-subdomains
> there is an interesting solution with multiple wildcards in the same
> cert:
>
> foo.com
> *.foo.com
> *.*.foo.com
> ...
>
> There is also the possibility that we can just grep the logs for every
> machine name ever accessed and generate a huge list.
>
> Has anyone tried these options? Successes? Failures? Thoughts?
>
> cheers
> stuart
>
>
> --
> ...let us be heard from red core to black sky