1

Our department's website uses the www subdomain, both internally and externally. When I joined, I noticed that a lot of users tried without the www, got an error, became confused or annoyed, until they tried with www or someone told them to. So, I added an internal DNS entry for the parent domain pointing to our web server (which didn't exist previously), and configured our web server to listen for both.

We were using self-signed certificates then. Recently, we got externally signed ones, but, in an oversight, only for *.parent.domain, not parent.domain. Thus, while the experience on www is generally smooth, when an unsuspecting user tries just https://parent.domain, they get an error. In terms of curl:

curl: (51) SSL: no alternative certificate subject name matches target host name 'parent.domain'

I added a redirect for HTTP requests, but the browser blocks further action for HTTPS, so the client never sees the redirect, but only a big, scary warning.

The certificates were obtained for three years, and I don't think I can justify a fresh expenditure just for this edge case. Is there anything I can do on the server-side to mitigate this?

muru
  • 589
  • 8
  • 26
  • 3
    Go have a chat with the certificate issuer. They may be able to fix this for free or a nominal cost. – Michael Hampton Sep 23 '15 at 04:58
  • Actually I don't see the reason for warning, *.parent.domain should match parent.domain without any SANs, just by design. I am using myself wildcard certificates on strict domains. Check https://enaza.ru - one of them. – drookie Sep 23 '15 at 05:12
  • 4
    @drookie Your certificate has enaza.ru in the SAN field. So this is a bad example. – Michael Hampton Sep 23 '15 at 07:44
  • @drookie No, it shouldn't. That's clearly specified in the relevant RFC. – Jenny D Sep 24 '15 at 04:22
  • @JennyD I'm curious though: what's the benefit from not matching `domain` when matching every `*.domain `? Some security reason I'm not seeing? – muru Sep 24 '15 at 04:37
  • 1
    @muru Here's an obvious example: An provider that allows customers to have their own subdomains, e.g. `jenny.example.com`, and allows said customers to run CGI scripts. This setup is usually crackable - but if it does get compromised, the perpetrator can only impersonate the site's customers, not the site itself. – Jenny D Sep 24 '15 at 07:14
  • @drookie and muru - here's the RFC https://tools.ietf.org/html/rfc2818#page-5 – Jenny D Sep 24 '15 at 07:17
  • @MichaelHampton contacted, no luck. The tech support kept spewing BS that redirection works fine (and gave `google.com` as an example!). – muru Sep 24 '15 at 10:36

2 Answers2

1

Redirection will happen AFTER the connection is established - therefore, without fixing the certificate, it can't be done. Why are users starting with HTTPS? Can't they just connect to non-SSL parent domain where the redirection will occur?

muru
  • 589
  • 8
  • 26
Arek B.
  • 317
  • 1
  • 3
  • 12
  • I'm not sure how they ended up at the SSL parent domain. An old redirect cached by the browser? I just had a few users inform me that certificate errors were showing up, and then I explained to them that only the `www.` address is certain to work. – muru Sep 24 '15 at 03:15
1

Depending who your SSL provider is they typically give you the root domain plus the www. This only works if you requested example.com, if they filled out the csr for www.example.com, they got www.www.example.com additionally, (test if your SSL works with www.www.example.com and you will know for sure).

You can always rekey, if you have issues using a new csr, contact your SSL provider and see if they will issue you a credit for the remaining term, you will however, be required to revoke the certificate before a credit is issued, causing an outage so plan for it.

Also, my *.example.com SSL covers example.com in the SAN.

I hope this helps.

Jacob Evans
  • 7,886
  • 3
  • 29
  • 57