When implementing WebSocket (ws.mysite.example) alongside your main domain (mysite.example), you're facing a classic infrastructure dilemma. Modern security practices demand SSL encryption for all endpoints, but certificate management can become complex quickly.

You have three main approaches to consider:

1. Individual Certificates:
   - mysite.example.crt
   - ws.mysite.example.crt
   - api.mysite.example.crt

2. Wildcard Certificate:
   - *.mysite.example.crt

3. Multi-Domain (SAN) Certificate:
   - mysite.example
   - ws.mysite.example
   - (additional SAN entries)

For wildcard certificate implementation:

server {
    listen 443 ssl;
    server_name ws.mysite.example;
    
    ssl_certificate /etc/ssl/certs/wildcard.mysite.example.crt;
    ssl_certificate_key /etc/ssl/private/wildcard.mysite.example.key;
    
    location / {
        proxy_pass http://websocket_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Modern TLS/SSL implementations (SNI - Server Name Indication) allow multiple certificates on a single IP address. You only need dedicated IPs if:

• Supporting very old clients (IE6 on WinXP)
• Using certain legacy applications

Wildcard certificates typically cost 2-3x a standard certificate but become economical beyond 3 subdomains. Consider:

For dynamic environments, Let's Encrypt with DNS challenges simplifies management:

certbot certonly \
  --manual \
  --preferred-challenges=dns \
  --server https://acme-v02.api.letsencrypt.org/directory \
  --agree-tos \
  -d 'mysite.example' \
  -d '*.mysite.example'

When using SSL with WebSocket (wss://), ensure your NGINX config includes:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 86400; # For persistent connections

When securing multiple subdomains like ws.mysite.example and domain.example, you have three main SSL certificate options:

• Individual certificates: Separate certs for each subdomain
• Wildcard certificate: Single cert covering *.mysite.example
• Multi-domain (SAN) certificate: Single cert with multiple Subject Alternative Names

Modern servers support SNI (Server Name Indication), eliminating the need for dedicated IPs per subdomain. NGINX configuration example:

server {
    listen 443 ssl;
    server_name ws.mysite.example;
    ssl_certificate /path/to/ws.crt;
    ssl_certificate_key /path/to/ws.key;
    # WebSocket configuration
    location / {
        proxy_pass http://localhost:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

server {
    listen 443 ssl;
    server_name domain.example;
    ssl_certificate /path/to/domain.crt;
    ssl_certificate_key /path/to/domain.key;
    # Regular HTTP configuration
}

For multiple subdomains, a wildcard certificate is often more practical. Here's how to configure it in NGINX:

server {
    listen 443 ssl;
    server_name *.mysite.example;
    ssl_certificate /path/to/wildcard.crt;
    ssl_certificate_key /path/to/wildcard.key;
    
    # Dynamic subdomain handling
    if ($host ~* ^([^.]+)\.mysite\.example$) {
        set $subdomain $1;
    }
    
    location / {
        proxy_pass http://localhost:8000/$subdomain;
    }
}

For development or production use, consider automated certificate management:

# Install certbot
sudo apt-get install certbot python3-certbot-nginx

# Obtain wildcard certificate (DNS challenge required)
certbot certonly --manual --preferred-challenges=dns \
-d 'mysite.example' -d '*.mysite.example'

# Auto-renewal setup
echo "0 0,12 * * * root certbot renew --quiet" | sudo tee -a /etc/crontab

While wildcard certificates simplify management, they have some tradeoffs:

• Single point of failure - if compromised, all subdomains are affected
• Certificate transparency logs will expose all subdomains
• OCSP stapling works for the wildcard domain only

Regardless of your certificate choice:

1. Always use TLS 1.2 or higher
2. Implement HSTS with includeSubDomains directive
3. Rotate certificates regularly (every 90 days for Let's Encrypt)
4. Monitor certificate expiration with tools like Nagios or Zabbix