We've got a website that is served on both www.example.com and just example.com - we've never done any sort of forcing users from one domain to the other, so if they land on example.com then that's where they stay, and I'm guessing that of those who bookmark our pages they'd be about a 50/50 split (there was an issue earlier on where some of our material omitted the WWW and years later we're still noticing a traffic split).

We're now adding SSL. We're not forcing SSL until the user hits the login or register page. Which domain should we run our SSL on?

  • www.example.com
  • example.com
  • secure.example.com
  • Something else?

I've done plenty of SSL sites before, but they were always designed with SSL in mind, and we always forced the www subdomain.

Are there pros and cons of doing it any of those ways? My primary concern is about the recognition of cookies, but seeing as we're forcing SSL on logon, the session cookie will be written on the SSL'd domain anyway. My primary concern is for people who might go to https://example.com when we're running the site on https://www.example.com, etc.

Another question would be, "Should I rewrite those who land on the non-www site to the WWW site?

  • Depending on who you buy your certificate from, they may give you the naked domain as a subject alternate name for free. So if you buy www.example.com you may get a certificate that covers both www.example.com and example.com. Commented Apr 16, 2013 at 3:20

2 Answers 2


I usually go with secure.domain.com because it gives me more flexibility as far as administration. For instance, I can put that subdomain on another server, behind some better IDS/IPS gear and possibly attach it to a private network that I don't want the web servers touching.

Its a good place to park multi purpose things, such as:

  • secure.domain.com/checkout/
  • secure.domain.com/portal/
  • secure.domain.com/support/

... etc.

  • Have you ever had troubles with cookies? For example if a cookie is created on www.example.com are you able to read it from secure.example.com? Commented Jul 30, 2010 at 21:11
  • @Farseeker: You can set the cookie for .example.com (or example.com, which is the same), and it will work for both www.example.com and secure.example.com (with the drawback, that it will always be sent to both subdomains). Here's my favorite page on this topic: code.google.com/p/browsersec/wiki/… Commented Jul 31, 2010 at 11:43
  • @Farseeker - Yeah, cookies propagate to subdomains, however if you are even the least bit clever its a non-issue. For instance, cookie->logged_in / connection->ssl, etc. Its not like a CDN where their absence is beneficial, they just have to be planned and managed.
    – Tim Post
    Commented Jul 31, 2010 at 20:39
  • @Chris, I wasn't aware you could set a cookie for example.com from www.example.com - I'll have to look into this. Thanks. Commented Jul 31, 2010 at 23:24
  • With this solution you can also deny secure.example.com in your robots.txt. So +1. :-)
    – fwaechter
    Commented Aug 1, 2010 at 21:57

Personally I just use DigiCert's SSL Plus certificate with does with example.com and www.example.com. As in your other question, I would still send everyone to www.example.com because it makes life easier later on. Doing this now, will also give you the opportunity to use something like secure.example.com later on.

I usually add code to detect if users are running HTTP when they should be running HTTPS and redirect them. I find this usually only happens during login, but depending on the site, it could happen other times too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.