1

I have several users who are encountering messages about secure connections to the server when trying to access my website.

  • We've had this on Mac (iphone, ipad and macbook w/ safari) & Windows (IE and Chrome).

  • This is happening on multiple ISPs in different towns.

  • The website address is a subdomain and does not have an SSL certificate installed - it isn't being accessed via https://.

  • The main domain does have an ssl certificate (not wildcard), and is showing no errors when checking.

I'm having trouble tracking down what the hell is happening. I suspect it's gotta be on our end with that number of people from different browsers / devices. I'm not even sure what question to ask next or how to isolate the issue. I'm also not able to duplicate the issue locally, which doesn't help.

How can I troubleshoot this??

Edit:

Here's a screenshot from the iphone user. I didn't include it earlier as I didn't think it told anything useful.

iphone screenshot

5
  • You'll need to get more detailed information/screenshots/etc from your customers that are seeing these errors.
    – EEAA
    Apr 28, 2015 at 21:15
  • @eeaa - I've only been able to get a screenshot from the iphone user (added to the post). I'm not even sure at this stage what to ask next?
    – Aninemity
    Apr 28, 2015 at 21:40
  • Do you by chance have the header Strict-Transport-Security being sent from your primary SSL domain with the includeSubDomains option? This would force compliant clients to connect to your subdomain over https even if they try connecting to http
    – drew010
    Apr 28, 2015 at 23:50
  • @drew010 - it would appear that I do! that'll be the problem then most likely. I'll get that sorted and will let you know if fixes. ta!!
    – Aninemity
    Apr 28, 2015 at 23:54
  • Cool I will post it as an answer and if that turns out to be the case you can accept.
    – drew010
    Apr 29, 2015 at 0:48

1 Answer 1

2

This could happen to clients if you primary domain sends a Strict-Transport-Security response header with the includeSubDomains flag.

Example header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

If this header is present with includeSubDomains, compliant clients that later access your subdomain will change all HTTP references to HTTPS and attempt to access the subdomain over https.

Unfortunately, if max-age in the header is set to something really high, clients will remember this value and continue to attempt to access your site over HTTPS even if you were to later remove that header. From the example above, clients will remember for 1 year that you required HTTPS when accessing the site and subdomains. If this is the case and a large number of users are running into this problem you may need to install an SSL certificate for any subdomains that were previously insecure.

From OWASP:

Use caution when setting excessively strict STS policies. Including subdomains should only be used in environments where all sites within your organization for the given domain name require ssl. Max-age limits should be carefully considered as infrequent visitors may find your site inaccessible if you relax your policy.

Before enabling includeSubDomains, also consider the impact of any existing DNS CNAME records for CDNs, email services, or other 3rd party services. Since includeSubDomains will force such CNAME subdomains to https:// it's likely the browser will throw a domain-mismatch error, which is hard to reverse because of the browser caching nature of HSTS.

References:

Wikipedia - HTTP Strict Transport Security

OWASP - HTTP Strict Transport Security

2
  • still working on getting the setting changed, but yeah the max-age is set to a year :/ is there no other way to force that as well? even from the client side?
    – Aninemity
    Apr 29, 2015 at 12:44
  • Since this security setting was designed to force future connections to be secure (to prevent various types of attacks) I would say first try removing the includeSubDomains flag, then consult with one of the users who is getting the error and see if they are later able to access your subdomain after first accessing the primary domain again. If their clients truly follow the recommendation, they will remember the max age of 1 year and still try to connect over https so the only option may be to obtain an SSL cert for your subdomain.
    – drew010
    Apr 29, 2015 at 16:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .