3 ms·

Tricky one. I don't think there's any way to solve that, other than creating certificates for every CNAME - which is too expensive and complicated for your clie

by jonasvp 14y ago

Tricky one. I don't think there's any way to solve that, other than creating certificates for every CNAME - which is too expensive and complicated for your clients. 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.

raverbashing 14y ago
It's really a major deficiency on how things work together (SSL, HTTP, CNAMEs) 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.
professorTuring 14y ago
You can solve this problem by using a "wildcard certificate". It's like 300$ more expensive than a normal one. You can test how it works creating your own: http://www.justinsamuel.com/2006/03/11/howto-create-a-self-signed-wildcard-ssl-certificate/ http://www.justinsamuel.com/2006/03/11/howto-create-a-self-s...
- mootothemax 14y ago
  You can solve this problem by using a "wildcard certificate". It's like 300$ more expensive than a normal one. 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 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.
  - professorTuring 14y ago
    I misunderstood your original concern :S, I meant what you said in your edit. I don't think there is a nice solution for the other problem =)
- Carolinaeliz 14y ago
  http://www.instantssl.com/wildcard-ssl.html http://www.instantssl.com/wildcard-ssl.html Presently we are using this and good to use it!
jcoby 14y ago
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.
- SoftwareMaven 14y ago
  The one-ip to one-ssl-host thing was solved quite some time ago with Server Name Indication[1]. 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. 1. http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication
  - jcoby 14y ago
    I mentioned SNI in my post. It doesn't work for anyone using IE (any version) on Windows XP. Unfortunately, that's enough people to make it impossible to use unless you have an extremely tech-saavy customer base.

by jonasvp 14y ago

raverbashing 14y ago

It's really a major deficiency on how things work together (SSL, HTTP, CNAMEs) 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.

professorTuring 14y ago

You can solve this problem by using a "wildcard certificate". It's like 300$ more expensive than a normal one. You can test how it works creating your own: http://www.justinsamuel.com/2006/03/11/howto-create-a-self-signed-wildcard-ssl-certificate/ http://www.justinsamuel.com/2006/03/11/howto-create-a-self-s...

mootothemax 14y ago
You can solve this problem by using a "wildcard certificate". It's like 300$ more expensive than a normal one. 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 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.
- professorTuring 14y ago
  I misunderstood your original concern :S, I meant what you said in your edit. I don't think there is a nice solution for the other problem =)
Carolinaeliz 14y ago
http://www.instantssl.com/wildcard-ssl.html http://www.instantssl.com/wildcard-ssl.html Presently we are using this and good to use it!

jcoby 14y ago

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.

SoftwareMaven 14y ago
The one-ip to one-ssl-host thing was solved quite some time ago with Server Name Indication[1]. 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. 1. http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication
- jcoby 14y ago
  I mentioned SNI in my post. It doesn't work for anyone using IE (any version) on Windows XP. Unfortunately, that's enough people to make it impossible to use unless you have an extremely tech-saavy customer base.