This is an interesting one. The first impulse is to simply answer NO, you can’t do it, that’s the point of HTTPS. But it’s all about networking and one can do quite some magic with proxies, forwarding, and the SNI extension in TLS protocols.

The correct answer is YES, one can install SSL certificates on a server with another domain name but it needs a bit more additional configuration to get it working as expected. You first need to “link” the domains in question together. There are legitimate reasons for doing that. It is useful for scalability, use in internal networks, testing, or demonstration purposes. When you think about it, and try it, e.g., CDN (content delivery networks) will direct tens or hundreds of domain names to the same IP address and they couldn’t do it without exactly this kind of configuration.

Also, there are so-called multi-domain, or SAN certificates, which may contain tens of completely unrelated domain names. When you install such a certificate (and its private key) on one of those domains, you will also become trusted for all other domains in that given certificate.

Let’s say “one domain” (name in the certificate) is called MASTER and “another domain” (where you want to install it) is SHADOW.

Unless you set up a redirection or a proxy pointing to a domain on the server with the MASTER IP address (as set up in DNS), the certificate will not be trusted by browsers as they send requests to the resolved IP addresses. (hence the DNS configuration). As one web server can host several domains, browsers will store the domain name they want in an SNI value inside HTTPS requests.

As one web server can host several domains, browsers will add the domain name they want in the SNI extension inside HTTPS requests so that it doesn’t get “lost”. The web server (be it Apache, nginx, or other) will use this SNI value to decide which of its configurations, it will apply and which website/web pages it will send back to the browser.

Caption: Learn more about multi-party encryption at our page for DEFCON-25 talk (https://mpc.enigmabridge.com).

Getting certificate for domain MASTER

Getting a certificate for domain MASTER. If you want such a certificate to be issued by a “trusted” CA you will have to control the domain MASTER! Any certification authority will require you to show that you control the MASTER domain. It can be via email, adding a file to your web server, adding an authorization data to your DNS records. This is the complicated part of HTTPS/TLS.

Getting certificate for domain MASTER on server SHADOW

If you expect me to say that you simply copy the certificate and its private key between the two servers, I will not. As you are likely to use Let’s Encrypt, I will focus on it. When you request a new certificate, you need to get an authorization. It’s a token stored by Let’s Encrypt for your “account key”  and it’s valid several days. So long as this token (authz) is valid, you can request certificates for the given account with re-authentication.

All you have to do is the following:

1. once only – copy the account key from the MASTER to the SHADOW server.
2. whenever you need a new certificate for the domain MASTER on the SHADOW server, you:
   1. request a new certificate on the server MASTER; and
   2. request a new certificate for the same domain on the server SHADOW with “renew” switch, if it exists. This must be done within a few days.

Installing certificate on server SHADOW

You can install any certificate you want on any server you have access to, as long as you also have the private key. Some applications will have a default certificate out of the box, e.g, the domain “default” and as such, your server will have a certificate for the “default” domain. Not that it would be of much use 🙂

The hard bit is how to make browsers and other clients accept that certificate. You can make the certificate “valid” either by configuring the server or your client.

Configure client. You can define the IP address for a particular domain on any computer – Linux, Mac, Windows in so-called “hosts” file. When the computer resolves domain to IP address, “hosts” file has the highest priority and you can use it to ensure that whenever you want to connect to the domain MASTER, your computer will use the IP address of the domain SHADOW.

So if SHADOW has IP address 147.23.23.23 and you change your “/etc/hosts” to contain:

147.23.23.23 MASTER

When you now type  the MASTER domain to your browser, the request will be sent to SHADOW, where you have the certificate for MASTER. Your browser will be happy and you get a green padlock in the browser.

Configure server. You can set either a proxy or create a redirect from your MASTER server to the SHADOW server. It means that when the MASTER receives a request from a client, it will forward it to the IP address of the SHADOW server. Anyone trying to connect to the MASTER domain will see “secure connection” even though the requests hit the SHADOW server. It may look suspicious, but this configuration is used fairly often.

It’s all about networking and “bonding” of domain names to IP addresses, and the IP addresses to actual servers.

If you want to get a little bit more insight into the configuration of a particular server, you can use our https://keychest.net spot check as it does not follow redirects. It will show if there’s a redirect in place though.

Try the Professional HTTPS/TLS monitoring service KeyChest.net to keep on top of your certificates and to keep 100% HTTPS uptime. The public cloud service is free and allows you monitor thousands of certificates within minutes (YouTube video – 49 seconds).