
Server Name Indication (SNI) is a TLS extension that allows the client to specify which domain it's connecting to during the TLS handshake — before any HTTP data is exchanged. Without SNI, a server could only present one certificate per IP address on port 443, because the TLS handshake happens before the HTTP Host header is sent. With SNI (supported by all modern browsers and TLS clients since 2010), the server inspects the requested hostname and presents the matching certificate for that domain. This means a single IP address can serve hundreds of domains, each with its own certificate.
Modern Nginx enables SNI by default. You don't configure SNI explicitly — it activates automatically when you define multiple server blocks on port 443, each with a different server_name and ssl_certificate.
The simplest approach: issue one certificate per domain via Certbot, and create a separate Nginx server block for each. This is the default when you run certbot --nginx -d domain.com for each domain. Each certificate renews independently so a renewal failure on one domain doesn't affect others.
A Subject Alternative Names (SAN) certificate covers multiple unrelated domains under one cert. Certbot accepts multiple -d flags to issue a single certificate covering all of them. The certificate will appear under the first domain's name in /etc/letsencrypt/live/. Note: Let's Encrypt allows up to 100 SANs per certificate. The trade-off is that all domains renew together — if renewal fails for any domain in the list, the whole cert fails to renew.
If your multiple “domains” are actually subdomains of a single parent (e.g. client1.youragency.com, client2.youragency.com), a wildcard certificate (*.youragency.com) is the cleanest option. One certificate covers all present and future subdomains and renews as a single unit. The trade-off is that wildcard certificates require DNS-01 challenge validation, which means you need API access to your DNS provider at renewal time.
At scale, keeping all virtual hosts in one nginx.conf becomes unmanageable. The standard practice is one config file per domain in /etc/nginx/sites-available/, symlinked to /etc/nginx/sites-enabled/. Nginx loads all configs from sites-enabled/ via the include /etc/nginx/sites-enabled/*; directive. To disable a site you remove the symlink without deleting the config file.
CloudStick abstracts all of the above. When you add a website on a CloudStick-managed server, the platform creates the Nginx virtual host configuration, issues a dedicated Let's Encrypt certificate for that domain, sets up the HTTP-to-HTTPS redirect, and configures auto-renewal — all without touching the command line. Adding 20 domains to a server takes 20 dashboard clicks, not 20 Certbot commands and 20 Nginx config edits. Each domain has its own certificate that renews independently, so a renewal hiccup on one site doesn't affect any other.


We use cookies to improve your experience
CloudStick uses cookies to personalise content, analyse traffic and keep you signed in. Cookie Policy · Terms of Service