I have created a web application for a client and I'm hosting it on my own server behind a domain I own. I have purchased an SSL certificate for this domain and the web application runs nicely over HTTPS.

The client has now created a CNAME record for his domain, pointing to my domain. But users who visit the application through his domain see a big SSL warning from browsers as the installed certificate is not for his domain.

The client is a huge multinational company and asking the relevant department for a correct certificate could take a long time. However I'm not even sure whether such a request would be reasonable at all and whether certificates would be passed around like that. Is there a certain best practice in solving such problems?

Update: I think I should clarify that the client's domain will be used for the final product and my domain will be out phased once the official switch has been made. So I basically want to know what is technically the easiest way for the client's tech department to help me out with securing the connection. So I do not need to secure both domains at the same time. Is it feasible for me to ask them to provide me a certificate for this domain or is there an easier way around it as they are already pointing to my server.

3 Answers 3


The trouble is that with HTTPS, SSL occurs first, and then HTTP within the SSL tunnel. When the server is contacted and must send its certificate, it does not know yet the server name that the client wants to talk with (the name for the URL that the client sees).

There are mostly three methods out of this:

  1. Use a different IP for each name. When the connection occurs, the IP address used by the client is known to the server, so the server could serve a different certificate based on that address.

  2. Use a certificate with several names. The client wants to see the intended server name in the certificate, but there can be more than one name in a certificate. The Subject Alt Name certificate extension can contain a lot of names (Google's certificates contain more than 70 names !).

  3. Have the client announce the intended server name sufficiently early in the SSL handshake. There is an SSL extension for that: Server Name Indication. The good news is that most Web browsers implement it. The bad news is that only most Web browsers implement it; in particular, Internet Explorer on Windows XP does not (IE 8 on Vista and later supports it, but not on XP).

See this site for statistics on Web browser usage over the Internet (use them as estimates, not as gospel; any given user community may exhibit different usage patterns). As of today (October 2013), IE 8 is announced at a bit less than 10% market share (the site does not say how many of these run on WinXP, but I'll bet that most of them do).

Method 3 is the "best practice", or at least will be the best practice in the near future. It is also the only method that you can implement right away without asking your big client to change his DNS or to request a certificate with the extra name.

  • Thanks for the answer. I actually do not need to support both at the same time, but find the technically easiest solution to propose to the client's tech department. I've edited my post.
    – garyp
    Oct 21, 2013 at 11:46

Solution 1

There is a way to do this, but it is so esoteric you would be better off waiting for the client company to give you an appropriate certificate (or see Solution 2). Especially as Solution 1* could open up certain audit risks, as auditors are a notoriously conservative about technological workarounds.

But if you and technicians at the client company prefer asking forgiveness instead of permission, you can do the following:

  1. Client techs set up a secure web service that has access to one of their SSL certificates that matches the client domain in question. This web service be locked down some insane degree specific to your server.
  2. Your server supports the Server Name Indication extension for TLS.
  3. If browser arrives with a RFC-6066 server_name matching your domain, proceed as usual. The browser happily gets the certificate for the domain they expected, all is merry in the world.
  4. If the browser arrives with a RFC-6066 server_name matching your client's domain, switch your TLS handshake into transparent proxy mode and forward all traffic to the client's special web service**. You are now acting as proxy/packet router - no funny man-in-the-middle stuff going on.
  5. Client's web service does its business with the certificate the browser expects and returns an encrypted 302 temporary redirect to your domain. e.g. https://client.com => https//vendor.com. It is all this client web service needs to do.
  6. The TLS connection is severed. And later on you get a different connection request for HTTPS to your domain from that browser. Not that you ever knew they got a redirect instruction, as that was traffic you couldn't decrypt but simply proxied. ;-)


A. Browser ===[client.com]==> https://vendor.com ==(client W/S)==> https://client.com

B. https://client.com ==[302 redirect]==> http://vendor.com ==[302 redirect]==> Browser

C. Browser ==[vendor.com]==> https://vendor.com

* Solution 1 occurred to me first and it does allow to the (misconfigured?) CNAME to stay pointing to the vendor IP; otherwise I'd make Solution 2 the first solution.
** I've never seen this in the wild, so I'm not sure if a transparent proxy half way through a SSL handshake would work in practice.

Solution 2

Solution 1 of course assumes they are not hiding your service underneath their domain for XSS or various other content aggregation reasons.

If they are, the far more common solution is to ask them to not set their domain CNAME to your IP* but to setup a client HTTPS reverse proxy that communicates with your site under the hood.

* Stupid thing to do for HTTPS - due to the ownership and control ambiguity it causes vendors.

  • Thanks for this information, very useful. However I'm doubtful whether the client techs would get this done in time. I've made an edit to my question with more info.
    – garyp
    Oct 21, 2013 at 11:46
  • 1
    @garyp In light of your new information, I'd suggest the alternative in last sentence (a client HTTPS reverse proxy) as they won't have scrap their existing certificate for a better certificate with extra Subject Alt Names. Oct 21, 2013 at 11:51

Yes, you can run multiple SSL-Certs via multiple Hostnames on the same server.

What webserver do you use? i think this is rather a topic for serverfault.

  • If I've read the OP's question correctly, they don't have a SSL cert for the domain in question. (i.e. The TLS SNI extension may not be sufficient) Oct 21, 2013 at 9:21
  • you can run multiple ssl-host on multiple IPs on the same host then, no need for SNI. Oct 21, 2013 at 9:29
  • But without access to the SSL cert (and private key), browsers will reject the handshake unless SSL traffic is proxied or redirected in some way by a server with access to the required certificate. I believe the OP hasn't been given the SSL key pair of the client's domain as this would open up the client to possible abuse by the vendor. Oct 21, 2013 at 11:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .