joewalnes/websocketd · error
please specify both --sslcert and --sslkey when requesting…
Error message
please specify both --sslcert and --sslkey when requesting --ssl
What it means
validateSSL enforces that when --ssl is requested, both the certificate and key files must be provided. Enabling TLS with only one of them leaves the listener unconfigurable, so startup fails with this message.
Solutions
- Pass both flags: --ssl --sslcert /path/cert.pem --sslkey /path/key.pem
- Generate a self-signed pair for testing, e.g. openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem
- Remove --ssl if you actually want plain HTTP/WS
Example fix
// before websocketd --ssl --port=443 ./script.sh // after websocketd --ssl --sslcert=cert.pem --sslkey=key.pem --port=443 ./script.sh
Defensive patterns
Strategy: validation
Validate before calling
if (useTLS && (!certPath || !keyPath)) throw new Error('--ssl requires both --sslcert and --sslkey'); Type guard
const sslConfigOk = (c) => !c.ssl || (Boolean(c.sslcert) && Boolean(c.sslkey));
Try / catch
try { startServer(cfg) } catch (e) { if (/sslcert and --sslkey/.test(e)) console.error('supply both cert and key or drop --ssl'); throw e; } Prevention
- Generate cert+key together with openssl and store both paths in your deploy config
- Validate the full flag set in your launch script before exec'ing websocketd
When it happens
Trigger: Running websocketd with --ssl but omitting --sslcert, --sslkey, or both, i.e. ssl==true while certFile or keyFile is an empty string.
Common situations: Enabling --ssl during local testing without generating cert/key; forgetting the key path when cert and key live in different directories; config migration dropping one flag.
Understand the failure class
- SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.
Related errors
- you should not be using --ssl* flags when there is no --ssl…
- --anyorigin means 'accept any origin' and cannot be…
- --maxframesize must not be negative; use 0 for unlimited
- please only specify one of --binary and --passstderr
- --socketmode 0 would make the socket unusable; pick a mode…
AI-assisted analysis of joewalnes/websocketd@7a8683dc7f (2026-09-03).
Data as JSON: /api/errors/46767bc6effddc25.
Report an issue: GitHub.
Appendix: source
Thrown at config.go:137
return 443
}
return 80
}
// wantsUnixSocketOnly reports whether the user asked to serve exclusively
// over a Unix domain socket, with no TCP listener at all. This holds only
// when --unixsocket is given and nothing else implies a TCP listener is
// wanted (--port, --address, or --redirport); otherwise the Unix socket
// (if any) is served alongside the usual TCP listener(s).
func wantsUnixSocketOnly(unixSocket string, portFlag int, addrlist []string, redirPort int) bool {
return unixSocket != "" && portFlag == 0 && len(addrlist) == 0 && redirPort == 0
}
// validateSSL checks that SSL-related flags are consistent.
func validateSSL(ssl bool, certFile, keyFile string) error {
if ssl {
if certFile == "" || keyFile == "" {
return fmt.Errorf("please specify both --sslcert and --sslkey when requesting --ssl")
}
} else {
if certFile != "" || keyFile != "" {
return fmt.Errorf("you should not be using --ssl* flags when there is no --ssl option")
}
}
return nil
}
// validateBinaryPassStderr checks that --binary and --passstderr aren't both
// set. Tagging binary chunks as JSON isn't implemented (--passstderr always
// reads line by line), so combining the two would silently discard --binary
// instead of behaving as either flag alone.
func validateBinaryPassStderr(binary, passStderr bool) error {
if binary && passStderr {
return fmt.Errorf("please only specify one of --binary and --passstderr")
}
return nilView on GitHub (pinned to 7a8683dc7f)