Installing the same SSL/TLS certificate on multiple servers can be accomplished using two primary methods. Sharing certificates between servers is a free feature with SSL.com certificates – you may rekey (reissue) a certificate as many times as needed at no extra charge. Below, we outline two approaches for sharing or deploying certificates across servers, followed by recommendations for automation and management.
The first method involves creating a .pfx file (PKCS#12 archive) containing your certificate, its intermediate certificates, and the private key, then importing that .pfx onto other servers. (Many cloud providers, such as Microsoft Azure, require uploading a certificate in .pfx format to use their services.) Steps: Export a .pfx file from the server where the certificate is installed. You can use or the Windows Certificate Export wizard (see ). These guides will combine your private key, server certificate, and any required intermediates into one PFX file. Import the .pfx file on each additional server that needs the certificate. For Linux/Unix systems, you can use OpenSSL to extract the certificate and key from the PFX (refer to SSL.com’s guide on ). On Windows servers, you can import the PFX using the Certificates MMC snap-in or IIS Manager – see . Configure the server to use the imported certificate. This typically involves binding the certificate to your site or service. For example, in IIS you must bind the certificate to the website’s HTTPS port and IP (SSL.com provides a guide on for reference). On other servers, update the configuration to point to the new certificate and private key files. Once configured, the server will use the shared certificate for secure connections.Method 1: Sharing Certificates via PFX File
The alternative method is more secure for large deployments, but involves additional certificate management. If you prefer each server to have its own private key and certificate (rather than sharing the exact same key), you can re-issue your SSL.com certificate for each server using a new CSR and key pair: Steps: Generate a CSR and private key on each server that needs the certificate. Follow platform-specific guidance to create a new Certificate Signing Request: For Linux/Unix Apache or Nginx servers, generate a CSR with OpenSSL (see for Apache/Nginx environments). For Windows/IIS, use the server’s GUI or PowerShell to create a CSR (refer to SSL.com’s how-to on ). For WHM/cPanel, use cPanel’s SSL/TLS interface to generate a CSR (see ). Each server will now have its own private key and CSR. Reprocess your certificate order at SSL.com with the new CSR. In your SSL.com account portal, locate your certificate order and use the Rekey/Reprocess option to submit the new CSR. (SSL.com provides a step-by-step guide on for this purpose.) This will generate a new certificate from the CA that matches the server’s CSR. Each time you do this, you’ll receive a new certificate (while the previous certificates for other servers remain valid as well). Install the new certificate on the respective server. After reissue, download and install the certificate files on that server just as you would a normal single-server certificate. For example, follow instructions to install in , , , or , depending on your platform. Once installed and configured, that server will use its unique certificate (with its own private key). Repeat this process for each additional server as needed. (All of the issued certificates relate back to your original order and will be covered under the same issuance terms.)Method 2: Unique Certificates per Server
Automating SSL/TLS Certificate Management
Manually exporting, copying, and reissuing certificates can become cumbersome as the number of servers grows. For improved efficiency and security, consider these automation tools and solutions provided by SSL.com and the community:
-
ACME Protocol Automation – SSL.com supports the Automated Certificate Management Environment (ACME) for hands-free certificate issuance and renewal (). ACME clients such as Certbot (the EFF’s popular ACME tool for Let’s Encrypt) and Kubernetes cert-manager can be pointed at SSL.com’s ACME endpoint to automatically request and install certificates on your servers. This allows you to seamlessly keep certificates synchronized and renewed across multiple systems. For more information, read SSL.com’s overview of and how it can streamline certificate management. Certbot’s documentation is available on the for various platforms, and the Kubernetes cert-manager project is documented on the – both are compatible with SSL.com’s ACME services. Using ACME, you eliminate most manual steps, as certificate lifecycle tasks (issuance, renewal, revocation) are handled by the client software in a standardized way.
-
SSL.com SSL Manager – For Windows environments, SSL.com offers the SSL Manager application is a free GUI tool that allows you to order, install, and manage SSL/TLS certificates (and even code signing and document signing certificates) directly from your desktop. It simplifies tasks like generating CSRs, installing certificates to Windows certificate stores, and converting certificate formats, all in one place. This can be especially useful if you need to deploy a certificate to multiple Windows servers or services – you can manage keys and certificates with a few clicks instead of running manual commands. SSL Manager also integrates with hardware token devices (e.g. YubiKey) for certificate storage. Using SSL Manager can save time and reduce the chance of errors when dealing with several Windows servers.
-
Hosted PKI Solution – For enterprise deployments or large-scale needs, consider SSL.com’s Hosted PKI platform. SSL.com’s lets organizations leverage SSL.com’s cloud-based certificate infrastructure to issue and manage certificates via a web interface or API. This solution can centralize the management of certificates for multiple servers, applications, and even IoT devices (). With a hosted private CA/RA (Registration Authority) service, you won’t need to run your own certificate authority – SSL.com handles the heavy lifting (secure key management, infrastructure, audits), while you control certificate issuance policies and automation through easy-to-use tools or RESTful APIs. This is ideal for automating certificate deployment in complex environments, and it can be integrated into your CI/CD pipelines or DevOps workflows for seamless scalability.
-
Scripting and DevOps Tools – In addition to the above, you can incorporate certificate tasks into your configuration management or deployment scripts. For example, on Linux you might use shell scripts with OpenSSL commands to distribute and reload certificates, and on Windows you can use PowerShell scripts (refer to Microsoft’s for guidance) to import certificates and bind them to services. These approaches, combined with the ACME protocol or SSL.com APIs, allow for end-to-end automation in your DevOps processes. By scripting certificate operations, you reduce manual effort and minimize the risk of downtime due to expired certificates or configuration errors.
Support and Contact
Managing SSL/TLS certificates across multiple servers can raise questions. If you need any assistance, SSL.com’s support team is here to help. You can find answers to common questions in the , which offers detailed how-to articles and FAQs. For personalized support, please
