自有域名TLS证书部署AWS Elastic Beanstalk上的NodeJS+Nginx WebSocket应用

Alright, let's tackle your problem step by step. You've got a Node.js + Nginx WebSocket app that works fine with self-signed certs, but one client refuses to accept them. You need a trusted TLS cert for your subdomain that also plays nicely with your AWS Elastic Beanstalk URL—here's how to make that happen:

The easiest (and free) way to get a widely trusted cert is using Let's Encrypt with Certbot. Let's assume your subdomain is ws.yourdomain.com:

• If you already have Nginx configured to serve traffic for this subdomain, run this command to auto-generate and install the cert:

  certbot --nginx -d ws.yourdomain.com
  

  Certbot will automatically update your Nginx config to use the cert and set up auto-renewal (critical since Let's Encrypt certs expire every 90 days).
• If you haven't set up Nginx yet, first point your subdomain's DNS record (A or CNAME) to your Elastic Beanstalk environment's IP or load balancer DNS. Then use the webroot method to get the cert:

  certbot certonly --webroot -w /path/to/your/apps/webroot -d ws.yourdomain.com
  

  You'll need to manually add the cert paths to your Nginx config later.

Update your Nginx config (usually in /etc/nginx/sites-available/ or /etc/nginx/conf.d/) to proxy WebSocket traffic over HTTPS. Here's a sample config:

server {
    listen 443 ssl;
    server_name ws.yourdomain.com;

    # Paths to your Let's Encrypt cert files
    ssl_certificate /etc/letsencrypt/live/ws.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ws.yourdomain.com/privkey.pem;

    # WebSocket proxy settings
    location /ws {
        proxy_pass http://localhost:3000; # Match your Node.js app's listening port
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

# Force HTTP traffic to redirect to HTTPS
server {
    listen 80;
    server_name ws.yourdomain.com;
    return 301 https://$host$request_uri;
}

After updating the config, restart Nginx to apply changes:

sudo systemctl restart nginx

Elastic Beanstalk's default URL (e.g., yourapp.elasticbeanstalk.com) is managed by AWS, so you can't directly replace its certificate. Instead, use one of these practical workarounds:

• Primary Solution: Route All Traffic Through Your Custom Subdomain
  Keep your clients connecting to wss://ws.yourdomain.com/ws (note the wss:// protocol for secure WebSockets). Ensure your DNS points this subdomain to your EB environment:
  • If using a load balancer, set a CNAME record for ws.yourdomain.com pointing to your EB environment's load balancer DNS.
  • If it's a single-instance EB environment, set an A record pointing to the instance's public IP.
    This way, all traffic uses your trusted cert, and you don't need to worry about the EB default URL at all.
• Alternative: Attach Your Cert to EB's Load Balancer
  If your EB environment uses an Application or Classic Load Balancer, upload your Let's Encrypt cert to AWS IAM (you'll need to convert the PEM files to the format AWS accepts), then configure the load balancer to use this cert for HTTPS listeners. While the EB default URL will still use AWS's cert, your custom subdomain will use your trusted cert, which is all your client needs.

Since Nginx is now handling TLS termination, your Node.js app can run over plain HTTP (no need to set up HTTPS in app.js). Just make sure it's listening on the correct localhost port (matching the proxy_pass in your Nginx config):

const WebSocket = require('ws');

// Listen on localhost:3000
const wss = new WebSocket.Server({ port: 3000 });

wss.on('connection', (ws) => {
    // Your WebSocket logic here
    ws.on('message', (data) => {
        console.log('Received:', data);
        ws.send('Hello from server!');
    });
});

• Test the WebSocket connection with a tool like wscat:

  wscat -c wss://ws.yourdomain.com/ws
  

• Verify the cert is trusted by visiting https://ws.yourdomain.com in a browser—you should see a padlock icon with no warnings.
• Test the problematic client to confirm it connects without issues.

内容的提问来源于stack exchange，提问作者jon