Using One SSL Certificate on Multiple Servers: Licences, Keys and Reissues

Can you use the same certificate on multiple servers?

Yes, on every platform, with no technical trick involved. During a TLS handshake the server sends its certificate and then proves it holds the matching private key. Nothing in that exchange identifies the machine, counts installations or phones the CA, so a certificate copied to a second host works there exactly as it does on the first.

The certificate itself is public. It travels to every visitor who opens the site, and it is published in the certificate transparency logs the moment it is issued. Treating it as a licensed asset misreads what it is. The private key is the sensitive half, and the whole of this question is really about how many copies of that key you are willing to have.

Where people get caught out is assuming the CA will stop them. It will not, because it cannot see your infrastructure. If your agreement limits you to one server, exceeding it is a contract problem that surfaces during a support case or a renewal, not an error at install time.

Names, servers and keys are three questions

Three different questions get asked as one here, and each has a different owner. How many names a certificate covers is decided by the request you submit. How many servers you may install it on is decided by the order terms. How many copies of the private key exist is decided by how you deploy. Answering one of them does not answer the others.

The third row is the one nobody is asked about at checkout, and it is the one that decides what a breach costs you. A wildcard certificate answers the first row generously and says nothing at all about the other two.

What a server licence actually means

A server licence is a commercial term in your agreement with the CA, not a property of the certificate. It dates from an era when certificates were priced per physical machine, and several authorities still sell additional server licences as a line item. Others include unlimited installations in the base price. Both models issue an identical file.

To find out which one you have, read the product page and the subscriber agreement for the certificate you bought, or ask the reseller directly. Two things are worth confirming while you are there: whether reissues are free and unlimited, and whether support covers installations on hosts beyond the first. Those two answers matter more over a certificate lifetime than a small price difference.

Every certificate in our SSL certificate range is sold with an unlimited server licence and free reissues, so the number of hosts is a design decision on your side rather than a pricing one. If you are on a certificate from elsewhere, the terms are worth checking before you plan the rollout, because discovering a per-host clause after deployment is an awkward conversation at renewal.

How to install one certificate on a second server

Three files have to reach the second host: the leaf certificate, the intermediate chain, and the private key. Miss the chain and the site loads for you and fails for someone else, which is the single most common reason a second server behaves differently from the first. Miss the key and the server will not start.

1. Collect the bundle on the working server. On Linux that is usually the certificate file, a chain or fullchain file, and the key. Confirm they match by comparing the modulus of the key and the certificate before you move anything.
2. Move it over a channel that is already encrypted. SCP or SFTP, or a secret manager your configuration tooling already uses. Email, chat and shared drives leave a copy of the key in places you cannot revoke.
3. Lock the key down on arrival. Owned by root, readable by nobody else. A key that arrives world-readable in a web directory is a worse outcome than not having deployed it at all.
4. Point the configuration at the files and reload. Then verify from outside the network rather than from the box itself, because a local test does not exercise the chain the way a fresh client does.

Windows and Java take a different route to the same place. On Windows you export a PFX from the certificate store and import it on the target, which works only if the key was marked exportable when the request was created. If it was not, there is no file to copy and a reissue is the only way onto the second host. Java keystores take the same PKCS#12 bundle through keytool. The certificate file formats guide covers the conversions between them.

Whatever the platform, write down where the copies went. The inventory is the part that decays, and it is the part you need in a hurry on the day something goes wrong.

Reissue instead: same names, a key per host

A reissue re-cuts the certificate you already own onto a new key pair. Generate a fresh request on the second server, submit it, and the CA returns a certificate with the same names and the same expiry date, bound to a key that never left that host. Repeat per server. Most CAs treat reissues as free and unlimited inside the term you already paid for, so the usual cost is a few minutes each.

This removes the step where private keys travel between machines, which is where most accidental exposure happens. It also shrinks what a single breach costs: one host is revoked and replaced while the others carry on serving. For a small, stable set of origin servers, it is the pattern worth defaulting to.

Two caveats keep it honest. A reissue does not extend anything, since you are re-cutting a certificate inside the period you bought, and with a one-year product under current lifetime limits you will be reissuing at least once anyway just to stay covered. And validation still applies: domain control has to be current, so an organisation-validated or extended-validation certificate may need its paperwork rechecked if the reuse window has lapsed.

What breaks when one key sits on twelve hosts

A shared key makes every host that holds it as trustworthy as the least defended one. An attacker who reads the key off a forgotten staging box can impersonate every name in the certificate, and the only remedy is to revoke and replace it everywhere it is installed at once. That is a coordinated change across twelve machines under time pressure rather than a contained incident.

The timing is not yours to choose either. The CA/Browser Forum Baseline Requirements require a CA to revoke a certificate within 24 hours of a confirmed key compromise, so the replacement window is set by policy rather than by your maintenance calendar. Revocation is also indiscriminate: it applies to the certificate, so every server presenting it stops being trusted at the same moment. How quickly clients notice depends on how revocation is checked, which is its own uneven story.

Then there is drift. Copies outlive the reason they were made. Certificates turn up on decommissioned VMs, in golden images, in a container layer somebody built in 2024, and in the download folder of whoever did the original install. A wildcard amplifies all of this, because the same key now stands behind every subdomain in the set.

None of this makes copying wrong. Plenty of well-run estates distribute one key deliberately through a secret manager, with an inventory and an expiry. The failure mode is copying without a record of where the copies went.

Shorter lifetimes changed the arithmetic

As of 15 March 2026, publicly trusted TLS certificates max out at 200 days, and CAs issue 199 to leave margin. The limit drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029 under CA/Browser Forum ballot SC-081v3. A habit built around one replacement a year now runs twice a year, four times a year from 2027, and roughly eight times a year from 2029.

Multiply that by the number of servers holding a copy of the key and you get the number that predicts whether a manual process survives. Twelve servers sharing one key meant twelve key transfers a year under the old limits. It means 24 now, 48 from March 2027, and 96 from March 2029. Each one is a chance to fumble a permission, miss a host, or reload the wrong service.

This is what quietly converts the copy-the-key habit from workable into the source of your next outage, and it is why the per-host pattern earns its keep well before 2029. Where the hosts can run an ACME client, automated per-host issuance solves the whole thing: each server holds its own key, renews itself, and nothing is ever copied. The playbook for shorter lifetimes covers the inventory and automation side in more depth.

Which approach fits your setup

Start with where TLS terminates rather than with the licence. If encryption ends at one load balancer, CDN or reverse proxy, the certificate is installed once and the origin servers never see it. That single fact removes the problem for a large share of the estates that ask about it, and it is worth confirming before counting anything.

• One termination point. Install there and stop. Backends can run plain HTTP inside a trusted network, or their own internal certificates if the hop crosses anything you do not control. The TLS termination guide covers the re-encryption case.
• A handful of origin servers, no automation. Reissue the same names once per host. Free with most CAs, and the key never travels.
• A fleet with configuration management. One key distributed through the secret manager you already operate, with the hosts recorded and the rotation scripted.
• Hosts that can run an ACME client. Per-host automated issuance, which is the only option that gets easier rather than harder as lifetimes shrink.

If the estate is large enough that the choice is not obvious, count the names first. Working out whether one wildcard, one multi-domain certificate or several single-name certificates fits your naming usually settles the deployment question with it, and our certificate pricing lists what each type covers alongside the licence terms.

Frequently asked questions