How to Host Multiple SSL Certificates on One IP with Plesk SNI: Complete Guide

IPv4 address scarcity is a real operational constraint for web hosting providers. Traditionally, each domain serving HTTPS required its own dedicated IP address to host a separate SSL certificate — a model that quickly exhausts IP pools on shared hosting servers. Server Name Indication (SNI) solves this problem by allowing multiple domains, each with their own SSL certificate, to share a single IP address.

If you manage a Plesk server and need to host SSL certificates for multiple domains on one IP, this guide covers everything: how SNI works in Plesk, the step-by-step assignment process, common SNI errors and how to fix them, and how SNI compares to wildcard and multi-domain (SAN) certificates.

What Is SNI and Why It Solves the Multiple SSL Problem

SNI is an extension to the TLS protocol that allows a client (browser) to specify which hostname it is trying to connect to at the start of the TLS handshake — before the server has sent any certificate. This lets the web server select the correct SSL certificate for that domain and present it to the client, even when hundreds of domains share the same IP address.

Without SNI, the server has no way of knowing which domain the client wants during the TLS handshake (because the HTTP Host header is only available after TLS is established). The server can only present one certificate per IP, which is why each domain traditionally required its own IP.

SNI is supported by all modern browsers and operating systems. The only notable exceptions are Internet Explorer on Windows XP and very old Android versions (pre-2.3), both of which have negligible market share today. For virtually all hosting environments, SNI works without client-side compatibility concerns.

Plesk SNI Support: Requirements and How It Works

Plesk supports SNI on both Linux and Windows servers, but with differences:

• Linux (Apache + nginx) — SNI is fully supported. Plesk uses nginx as the SSL termination layer by default on Linux servers, and nginx has supported SNI since version 0.5.23 (released 2007). No special configuration is needed to enable SNI — it works automatically when you assign SSL certificates to domains on a shared IP.
• Windows (IIS) — SNI is supported in IIS 8.0 and later (Windows Server 2012+). If your Plesk server is running IIS 7.x, SNI is not available and each domain with SSL requires a dedicated IP.

In Plesk's IP address model, IPs can be designated as either dedicated (one domain per IP) or shared (multiple domains per IP). SNI certificates work on shared IPs. When you assign an SSL certificate to a domain hosted on a shared IP, Plesk and nginx automatically use SNI to serve the correct certificate to each connecting client.

Step-by-Step: Assigning Independent SSL Certificates to Multiple Domains on One IP

The following process works for Plesk Obsidian on Linux. The same steps apply for Plesk Onyx with minor UI differences.

openssl s_client -connect SHARED_IP:443 -servername domain1.com 2>/dev/null | openssl x509 -noout -subject -dates
openssl s_client -connect SHARED_IP:443 -servername domain2.com 2>/dev/null | openssl x509 -noout -subject -dates

Common SNI Errors in Plesk and How to Fix Them

Wrong Certificate Served (All Domains Get the Same Certificate)

This usually means nginx is not correctly mapping SNI hostnames to the right virtual host configuration. In Plesk on Linux, nginx configuration files are generated automatically. Force a regeneration:

plesk repair web -all

This command regenerates nginx and Apache configuration for all domains. After completion, test again with openssl s_client -servername.

SSL Certificate Mismatch Warning in Browsers

A certificate mismatch warning ("Your connection is not private" with NET::ERR_CERT_COMMON_NAME_INVALID) when visiting a domain on a shared IP can mean:

• The domain does not have an SSL certificate assigned in Plesk — it is being served the default certificate from another domain on the IP
• The wrong certificate is assigned to the domain (for example, a wildcard for *.domain1.com is assigned to domain2.com)
• The SSL certificate has expired

Resolve this by going to Domains → [affected domain] → SSL/TLS Certificates and confirming a valid certificate is assigned and active for that domain.

"SSL SNI does not work for my domains" After Plesk Update

Plesk updates occasionally regenerate nginx configurations and can overwrite custom SNI settings. If SNI stops working after a Plesk update, run plesk repair web -all and check nginx error logs:

tail -50 /var/log/nginx/error.log

Look for no certificate found or SSL_CTX_use_certificate_file failed errors that indicate a certificate file path issue in the generated nginx configuration.

Let's Encrypt Certificate Fails to Issue on a Shared IP

Let's Encrypt domain validation requires that the domain resolves to a reachable server. On a shared IP, ensure:

• The domain's DNS A record points to the correct shared IP
• Port 80 is open and not blocked by the server firewall (required for HTTP-01 ACME challenge)
• No other domain's redirect rule is intercepting the /.well-known/acme-challenge/ path

SNI vs Wildcard vs Multi-Domain (SAN) Certificates: Choosing the Right Approach

SNI alone determines how certificates are served from a single IP — it does not dictate what type of certificate you use. Here is how the certificate types compare in a Plesk shared hosting context:

• Individual domain certificates with SNI — one certificate per domain, independently issued and renewed. Best for shared hosting where each customer owns their own domain and manages their own certificate. Let's Encrypt makes this free and auto-renewing.
• Wildcard certificates — one certificate covers all subdomains of a domain (*.example.com). Best for your own server's subdomains (mail.yourserver.com, admin.yourserver.com, etc.) or for clients who want SSL across all their subdomains with a single certificate. Cannot cover different root domains.
• Multi-domain (SAN) certificates — one certificate covers multiple explicitly listed domains (up to 100 SANs per certificate). Useful for organisations with multiple owned domains that want to manage a single certificate. Requires re-issuance whenever a domain is added or removed from the list.

For most Plesk shared hosting scenarios, the combination of a shared IP with SNI-based individual Let's Encrypt certificates per domain is the most operationally efficient approach: zero cost, automatic renewal, and no IP address overhead.

Checking and Managing SNI Certificates at Scale in Plesk

If you manage a Plesk server with dozens or hundreds of domains, tracking SSL certificate expiry across all SNI-hosted domains becomes important. Plesk provides a built-in SSL certificate overview in Tools & Settings → SSL/TLS Certificates (admin view) that shows all certificates across all subscriptions, their expiry dates, and whether auto-renewal is enabled.

For bulk Let's Encrypt certificate installation across all domains on a server, use the Plesk CLI:

# List all domains without Let's Encrypt certificates
plesk bin extension --exec letsencrypt cli.php -list

# Install Let's Encrypt for a specific domain
plesk bin extension --exec letsencrypt cli.php -d yourdomain.com

Maintaining SSL certificates across large Plesk deployments with mixed certificate types, custom CAs, and expiry monitoring is a significant operational overhead. CloudHouse Technologies' managed Plesk service handles certificate provisioning, SNI configuration validation, renewal monitoring, and emergency certificate replacement across all your managed Plesk servers.