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