While both SAN (Subject Alternative Name) and SNI (Server Name Indication) SSL certificates handle multiple domains, they operate at fundamentally different layers of the HTTPS stack. SAN certificates work at the certificate level, while SNI is a TLS protocol extension.

A SAN certificate contains multiple domain names in its Subject Alternative Name field. Example of how domains are listed:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 12:34:56:78:90:ab:cd:ef
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Example CA, CN=Example CA
        Validity
            Not Before: Jan 1 00:00:00 2023 GMT
            Not After : Jan 1 23:59:59 2024 GMT
        Subject: CN=primary.example.com
        Subject Alternative Name:
            DNS:secondary.example.com
            DNS:*.dev.example.com
            DNS:another.example.org

For Nginx using SNI:

server {
    listen 443 ssl;
    server_name domain1.example.com;
    ssl_certificate /path/to/cert1.pem;
    ssl_certificate_key /path/to/key1.pem;
    ...
}

server {
    listen 443 ssl;
    server_name domain2.example.com;
    ssl_certificate /path/to/cert2.pem;
    ssl_certificate_key /path/to/key2.pem;
    ...
}

For Apache using SAN:

<VirtualHost *:443>
    ServerName main.example.com
    ServerAlias alt1.example.com alt2.example.com
    SSLEngine on
    SSLCertificateFile /path/to/multidomain.crt
    SSLCertificateKeyFile /path/to/multidomain.key
    ...
</VirtualHost>

SNI requires client support (all modern browsers) while SAN works with any SSL/TLS client. However, SAN certificates have these constraints:

• All domains must share the same validation level (OV or EV)
• Certificate revocation affects all domains
• Adding domains requires reissuing the certificate

SNI offers better flexibility for managing certificates per domain, while SAN reduces the number of certificates needed. A benchmark test on a 4-core server showed:

From a security perspective, SNI provides better isolation between domains. If one private key is compromised in SNI setup, only that domain is affected. With SAN, all domains protected by that certificate become vulnerable.

Many enterprises use a combination of both. Here's a Node.js snippet demonstrating this:

const https = require('https');
const fs = require('fs');

const sanOptions = {
  key: fs.readFileSync('san-key.pem'),
  cert: fs.readFileSync('san-cert.pem'), // Contains multiple domains
  SNICallback: (servername, cb) => {
    if (servername === 'special.example.com') {
      cb(null, {
        key: fs.readFileSync('special-key.pem'),
        cert: fs.readFileSync('special-cert.pem')
      });
    }
  }
};

https.createServer(sanOptions, (req, res) => {
  res.end('Hello World!');
}).listen(443);

When setting up HTTPS for multiple domains, you'll encounter two primary certificate types: SAN (Subject Alternative Name) and SNI (Server Name Indication). While both enable multi-domain encryption, they operate at different layers of the TLS handshake process.

A SAN certificate contains multiple domain names within a single certificate file. Here's how you might configure one in Nginx:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/san_cert.pem;
    ssl_certificate_key /path/to/private.key;
    # This cert also covers www.example.com and api.example.com
}

SNI, by contrast, is a TLS extension that allows the client to specify the requested hostname during the handshake. This enables the server to present the correct certificate:

# Multiple server blocks with different certificates
server {
    listen 443 ssl;
    server_name domain1.com;
    ssl_certificate /path/to/domain1_cert.pem;
    ssl_certificate_key /path/to/domain1.key;
}

server {
    listen 443 ssl;
    server_name domain2.com;
    ssl_certificate /path/to/domain2_cert.pem;
    ssl_certificate_key /path/to/domain2.key;
}

SNI requires client-side support (all modern browsers do), while SAN certificates work with any TLS client. For legacy systems:

• Windows XP with IE6 won't work with SNI
• Android 2.x has partial SNI support

Use SAN when:
- You control multiple subdomains (blog.example.com, shop.example.com)
- Supporting very old clients is mandatory
- You want simplified certificate management

Use SNI when:
- Hosting completely separate domains (client1.com, client2.com)
- Need cost-effective solution (no need for multi-domain cert)
- Modern clients only

Both provide equal encryption strength. However, SAN certificates expose all domain names in the certificate transparency logs, while SNI reveals the hostname only during the TLS handshake.

Large SAN certificates (with 50+ domains) increase handshake size. SNI allows leaner configurations but requires more memory for multiple certificate contexts.