joewalnes/websocketd · error
you should not be using --ssl* flags when there is no --ssl
Error message
you should not be using --ssl* flags when there is no --ssl option
What it means
validateSSL rejects --sslcert/--sslkey given without --ssl. Supplying TLS material while TLS is disabled almost always signals a misconfiguration, so the server refuses to start rather than silently ignoring the flags.
Source
Thrown at config.go:141
// 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 nil
}
// validateAnyOrigin checks that --anyorigin is not combined with an actual
// origin policy. The flags say opposite things, and silently preferring oneView on GitHub (pinned to 7a8683dc7f)
Solutions
- Add --ssl to actually enable TLS with the given cert/key
- Remove the --sslcert/--sslkey flags if plaintext is intended
- Check for typoed flag names (e.g. --ss) that leave --ssl unset
Example fix
// before websocketd --sslcert=cert.pem --sslkey=key.pem --port=8080 ./script.sh // after websocketd --ssl --sslcert=cert.pem --sslkey=key.pem --port=8080 ./script.sh
Defensive patterns
Strategy: validation
Validate before calling
if (!useTLS && (certPath || keyPath)) throw new Error('ssl cert/key given without --ssl'); Type guard
const sslFlagsConsistent = (c) => c.ssl === Boolean(c.sslcert || c.sslkey);
Try / catch
try { startServer(args) } catch (e) { if (/no --ssl option/.test(e)) console.error('either add --ssl or remove --sslcert/--sslkey'); throw e; } Prevention
- Keep TLS flags grouped in one config variable so they are added/removed together
- Check for typos like --ss that silently leave --ssl unset
- Diff your command line against a known-good template after edits
When it happens
Trigger: Running websocketd with --sslcert and/or --sslkey while --ssl is absent (ssl==false and at least one file path is set).
Common situations: Removing --ssl to debug plaintext issues but leaving cert flags behind; a wrapper script that always appends --ssl* flags; typo'd flag such as --ss instead of --ssl going unnoticed.
Understand the failure class
- SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.
Related errors
- please specify both --sslcert and --sslkey when requesting -
- --socketmode %q is not an octal permission mode (e.g. 0700)
- --socketmode %q has bits beyond permission bits (keep it wit
- --socketmode 0 would make the socket unusable; pick a mode l
- please only specify one of --binary and --passstderr
AI-assisted analysis of joewalnes/websocketd@7a8683dc7f (2026-09-03).
Data as JSON: /api/errors/59de0e03f1176e1d.
Report an issue: GitHub.