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:
- 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.
- Your server supports the Server Name Indication extension for TLS.
- 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.
- 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.
- 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.
- 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 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.