Correct, it's really not a solvable problem. It boils down to two problems: 1) SSL hostname has to match the hostname on the cert and 2) you can (realistically)

Correct, it's really not a solvable problem. It boils down to two problems: 1) SSL hostname has to match the hostname on the cert and 2) you can (realistically) only have one cert per IP address. 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.