Node无法连接使用自签名证书的Tesla Powerwall服务器及远程访问问题求助

It looks like Tesla's Powerwall update did tighten up SSL/TLS validation rules, and the core issue boils down to your device's self-signed certificate not including your public IP or DDNS domain in its Subject Alternative Name (SAN). Here's how to fix your two problems:

a) Remote Browser Access via DDNS #

Browsers now strictly enforce that the domain/IP you're accessing matches an entry in the certificate's SAN. Your Powerwall's certificate only lists internal domains (powerwall, teg, powerpack) and local IPs (192.168.90.x/91.x)—it doesn't have your DDNS domain (home.xxxxxx.com) or public IP, which is why the connection fails.

Try these solutions, ordered by security and reliability:

1. Use a VPN to connect to your home network (most secure)
   Connect to your home VPN first, then access the Powerwall using its internal domain https://powerwall:4444. This domain is in the certificate's SAN, so once you trust the self-signed certificate, the browser will connect without issues. This also avoids exposing your Powerwall directly to the public internet.
2. Temporarily bypass browser hostname validation (not recommended long-term)
   • For Chrome: On the "Cannot establish secure connection" error page, type thisisunsafe directly on the page (no need to enter it in the address bar) to bypass the warning temporarily.
   • For Safari: Enable the Developer menu via Preferences > Advanced > Show Develop menu, then select Develop > Ignore Certificate Warnings. Note this is a global setting and reduces security for all sites.
3. Customize the Powerwall's certificate (advanced, may not be supported)
   Some Tesla devices allow uploading custom SSL certificates, but Powerwall likely doesn't support this. Check official docs or community forums to confirm—if possible, generate a self-signed certificate with your DDNS domain in the SAN and replace the default one.

b) Force Node.js to Ignore SSL Validation & Complete Connections #

Your current code disables certificate trust checks (rejectUnauthorized: false), but Node.js still validates that the hostname matches the certificate's SAN by default. This is why your AWS instance fails with both IP and DDNS. You need to bypass both checks:

Update your code to use a custom https.Agent that skips certificate trust and hostname validation:

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

// Create a custom agent to disable SSL validation entirely
const sslAgent = new https.Agent({
  rejectUnauthorized: false, // Skip certificate trust verification
  checkServerIdentity: (hostname, cert) => undefined // Skip hostname matching
});

request({ 
  url: 'https://your-ddns-or-public-ip:4444/api/system_status/soe', 
  method: 'GET', 
  agent: sslAgent, // Use the custom agent
  headers: headers 
}, (error, response, body) => {
  if (error) {
    console.error('Request failed:', error);
    return;
  }
  console.log('Response:', body);
});

The secureProtocol settings you tried didn't work because the issue wasn't TLS version mismatch—it was the hostname validation failing, which caused the connection to drop early.

Note: Disabling SSL validation reduces security, so only use this in trusted environments. For long-term use, connecting via VPN (and using the internal powerwall domain) is the safer approach.

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