General comments. There are a variety of architectures, with a differing level of robustness to security vulnerabilities in your server-side code.
The most robust strategy is to use an unrelated domain for each customer (e.g., customera.com, customerb.com). This gets you the full benefits of the same-origin policy. For instance:
If one customer's site has a security vulnerability (e.g., XSS), then attackers cannot use it as a jumping-off point to attack your other customers.
However, using one unrelated domain per customer makes you pay the cost of a separate domain per customer. That cost may not be necessary, depending upon your particular application.
The next-most robust strategy is to use a different subdomain per customer (e.g., customera.mysite.com, customerb.mysite.com). This gets you most of the benefits of the same-origin policy, but with some caveats and holes:
If you're not careful, code on one customer's site may still be able to read cookies from other customers' sites. In particular, it is important that all the cookies set by the site for customer A should have their domain attribute set to
.mysite.com (as explained by @dgarcia). If you control the server-side code and client-side code, you can enforce this. However, if you run customer-supplied code, it may be harder to enforce this requirement, and you may want to go with an unrelated domain per customer.
No matter how you configure your site, one customer's site will still have the power to set cookies for another customer's site. This is a little-known gap in the same-origin policy; customera.mysite.com can set a cookie with domain attribute
.mysite.com, and then that cookie will be sent along with all requests to customerb.mysite.com. (See also
This limitation might be acceptable in your application, or it might not. If it is not an acceptable risk, then you can use unrelated domains for each of your customers.
The least robust strategy is to serve all of your customers from your same domain (e.g., mysite.com/customera, mysite.com/customerb; or mysite.com with a different login per customer). The downside of this approach is that you can no longer rely upon the browser's same-origin policy to help you keep customers separate, so now the responsibility passes to your server. Don't get me wrong: this approach can definitely still be secure if your code is free of vulnerabilities and your code ensures that no customer can attack any other. This architecture is probably the most commonly found on the web: most user-facing websites use this architecture. The limitation of this architecture is that it is less robust to flaws in your server-side code; a XSS bug, failure of sanitization, or other problem in your code can enable one customer to attack another, or breach customer isolation.
For similar reasons, I don't see a strong reason why you need a different SSL certificate per customer. Therefore, I suspect you would be just fine with an architecture where you use a single domain and rely upon the server code to authenticate each customer and apply appropriate access controls to protect customers from each other.