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 one

View on GitHub (pinned to 7a8683dc7f)

Solutions

  1. Add --ssl to actually enable TLS with the given cert/key
  2. Remove the --sslcert/--sslkey flags if plaintext is intended
  3. 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

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

Related errors


AI-assisted analysis of joewalnes/websocketd@7a8683dc7f (2026-09-03). Data as JSON: /api/errors/59de0e03f1176e1d. Report an issue: GitHub.