This is especially important given that your domain name is less than ideal at present for support purposes; I've had enough of reading out hyphenated domains over the phone, and will avoid services that involve doing so.
Looks good though! Do you remember previous visits to the page as well?
I've run into this with Campaign Monitor and they simply don't do SSL for CNAMEs. Since they do everything else perfectly, I'm assuming there's no way to solve this problem.
Maybe the solution is having stuff.blah.com redirect to blah.com/stuff and do SSL from there
Ugly, but it gets the job done.
You can test how it works creating your own: http://www.justinsamuel.com/2006/03/11/howto-create-a-self-s...
Incorrect. You cannot create a wildcard domain for every domain in existence. That would somewhat undermine the whole point of SSL.
Edit: I think I misunderstood slightly. You're correct if you mean using the same domain for clients (e.g. client1.domain.com, anotherclient.domain.com), but not if you want clients to be able to use their own domains with your service.
On a related note, StartSSL (http://www.startssl.com) are a cheap option for wildcard certificates, and SSL certificates in general, since they only charge to validate your identity - you can issue as many certificates as you want (for domains you own) thereafter.
I don't think there is a nice solution for the other problem =)
For 1), you would have to upload the ssl cert and key into the third party's service. They would then have to configure their web server to use the correct ssl cert for your CNAME. On top of that they would need to add support for whatever intermediate and CA certs that have to be included. Some CAs require multiple intermediate certs. If you simply upload the main cert and key then older browsers, android, and IE will all freak out. I have missed an intermediate cert before and it's not fun to track down the root cause. There are no errors in apache; you just get reports of your site being compromised or the cert expired.
Not to mention the problem of SSL accelerators/load balances and costs associated with adding new SSL certs and keys to them.
Even if they figured out a way to automate the cert/key/PEM/intermediate upload and server config steps then the one IP per ssl cert problem kicks in. Basically, the SSL handshake goes something like this: 1) browser looks up IP address for host. 2) browser connects to IP and establishes a ssl connection. 3) server reads the request and serves up content based on hostname. The problem is that the server does not get the hostname during step 2 so it can only serve up one cert for the IP.
Now, there is a process called SNI that attempts to solve it. Unfortunately it's not well supported enough to use. Mostly because it does not work on IE on XP at all (regardless of version).
And that's why third parties generally don't offer SSL CNAMEs.
You still need one cert per host, but that is a cost that could be transferred to the customer (not the user getting logged but the one wanting the log :). You can get incredibly cheap certs that would probably be appropriate for this case.