Do You Need a Dedicated IP for SSL? SNI Explained

Every few weeks a customer asks us for a dedicated IP address so they can "install SSL properly." It's a fair question — ten years ago that was true. Today, on almost every modern host including Getwebup, it isn't. Here's what actually changed, how to check your own setup, and the handful of cases where a dedicated IP genuinely still matters.

Where the dedicated-IP myth comes from

Before around 2012, a web server could only present one SSL certificate per IP address. The TLS handshake happened before the browser ever told the server which hostname it wanted, so the server had no way to pick the right certificate — it just served whatever cert was bound to that IP. If you hosted shop.example.com and blog.example.net on the same shared IP, only one of them could have valid HTTPS. The fix, back then, was to buy a dedicated IP for each domain that needed a certificate. Older hosting guides (and a lot of outdated blog posts still floating around) never got updated, so the advice stuck.

What SNI changed

Server Name Indication (SNI) is a TLS extension that fixes exactly this problem. The browser sends the hostname it's connecting to during the handshake, before encryption starts, so the server can look up and serve the matching certificate on the fly — even if a hundred other domains share that same IP. Apache, Nginx, and LiteSpeed (the web server behind most cPanel accounts, including Getwebup's) have all supported SNI by default for years. cPanel's AutoSSL issues and installs Let's Encrypt certificates over SNI automatically; you never touch IP allocation to get HTTPS working.

In practice this means: dozens of unrelated customer domains on the same shared IP, each with its own valid, independent SSL certificate, no conflicts.

How to check whether your site is affected

You almost certainly don't need to do anything, but if you want to confirm your certificate is serving correctly on a shared IP, run this from a terminal (or use an online SSL checker):

curl -vI https://yourdomain.com 2>&1 | grep -i "subject:"

If the subject: line shows your domain's own name and not some other customer's certificate, SNI is doing its job. You can also check in a browser: click the padlock → certificate details → it should list your domain under "Issued to." A mismatch there is a real SSL problem worth investigating, but it's not caused by a shared IP — it's usually a misconfigured vhost or a stale cached certificate.

When a dedicated IP still genuinely matters

SNI isn't a 100% replacement for dedicated IPs in every situation. A few cases still call for one:

• Legacy clients that don't speak SNI. Very old software — Windows XP with IE on XP, Android 2.3 and earlier, some ancient payment terminals or embedded devices — can't send the SNI hostname and will get whatever certificate is bound to the IP by default. This mostly matters for niche B2B or POS integrations, not typical consumer traffic in 2026.
• Mail server TLS on your own hostname. If you run your own mail server and want mail.yourdomain.com to present a certificate that matches on connection without SNI-aware clients (some older desktop mail clients are picky), a dedicated IP for the mail service specifically can avoid warnings.
• Compliance or audit requirements. Some PCI-DSS assessors or enterprise security policies still specify a dedicated IP per SSL-bearing service, regardless of whether SNI would technically work. This is a policy requirement, not a technical one.
• IP-based reputation isolation. If your site shares an IP with something that gets blacklisted (spam, malware), a dedicated IP keeps your reputation separate. This is really an IP-reputation reason, not an SSL reason, but it's the most common legitimate request we see.

How this works on Getwebup / cPanel hosting

On shared and reseller hosting plans, every account sits behind SNI by default. AutoSSL runs every 90 days per domain, validates ownership, and installs the renewed certificate — all on the shared IP, with zero manual steps. If you're on a VPS, the same logic applies for your web server (Nginx/Apache virtual hosts), but you have the option to add a dedicated IP if one of the cases above applies to you. You'd request it through WHM (if you manage your own VPS) or by opening a ticket if we manage it, then bind the certificate to that IP in the vhost config or via a2ensite/Nginx server block.

Quick comparison

Prevention: don't pay for what you don't need

Before requesting a dedicated IP, check your actual traffic logs for the user agents you're worried about, or just ask your compliance team whether their policy is truly a hard technical requirement or an old checklist item nobody's revisited. In four out of five support tickets we get about this, the customer's real problem turns out to be something else entirely — usually a mixed-content warning, an expired cert, or Cloudflare's SSL mode set wrong — and a dedicated IP wouldn't have fixed any of it.

Prevention checklist

• Confirm AutoSSL is actually issuing per-domain certs in cPanel → SSL/TLS Status before assuming you need a workaround.
• Test your site with an SSL checker tool to rule out a genuine misconfiguration first.
• Only request a dedicated IP when you've identified a specific legacy client, compliance clause, or reputation-isolation need — not as a default "just in case."
• If compliance is the driver, get the exact clause from your auditor in writing before paying for the add-on.