On 14 Dec 2014 15:24, "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).

Huh, had not read RFC 6125 before but "Move away from the issuance of
so-called wildcard certificates (e.g., a certificate containing an
identifier for "*.example.com")." certainly caught me by surprise. I've
purchased a few certs in the past few months (including for our EZProxy
instance) and the issuer was still using CommonName and happy to issue
wildcard certs. And we haven't run into any SSL cert warnings with current
versions of Chrome or Firefox.

Can you provide more details about what you're trying to do and where
you're getting reproducible issues?

For EZProxy, our wildcard cert has a CommonName of *.proxy.example.com ;
proxy requests look like
http://login.proxy.example.org/login?url=proxied.url.example.com ; the user
is them redirected to
https://login.proxy.example.org/login?url=proxied.url.example.com to login,
and on a successful login they are redirected to
https://proxied-url-example-com.proxy.example.org

So far, so good for us. Should we be expecting trouble?

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

*.*.foo.com sounds unlikely to work in practice, as the answer provider
admits. I would be worried about wasting my money trying this approach.