 |
 |
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