RMI Ports and Security

A first distributed JMeter run usually fails twice before it ever sends a request: once on ports, and once on this. The second failure is the one that reads like a configuration mistake but is actually the shipped default doing its job. ## The default `RmiUtils` reads `server.rmi.ssl.disable` with a default of `false`. Both `createClientSocketFactory()` and `createServerSocketFactory()` return `null` — meaning plain RMI sockets — only when that property is `true`. Otherwise they construct an `SSLRMIClientSocketFactory` / `SSLRMIServerSocketFactory` and configure it from the rest of the family: | Property | Default | |---|---| | `server.rmi.ssl.keystore.file` | `rmi_keystore.jks` | | `server.rmi.ssl.keystore.type` | `JKS` | | `server.rmi.ssl.keystore.password` | `changeit` | | `server.rmi.ssl.keystore.alias` | `rmi` | | `server.rmi.ssl.truststore.file` | the keystore file | | `server.rmi.ssl.truststore.password` | the keystore password | | `server.rmi.ssl.disable` | `false` | The truststore properties falling back to the keystore values is what makes a **single shared file** workable: one `rmi_keystore.jks` is simultaneously the node's identity and the set of identities it accepts. ## Why one file has to reach every node `RmiUtils.createServerSocketFactory()` calls `factory.setNeedClientAuth(true)`. Both ends therefore have to present a key, not just validate one, so the controller needs the same file the generators have. Copy it to `bin` on each machine, or point `server.rmi.ssl.keystore.file` at an absolute path — the default is relative, which is why the manual tells you to run the generator script from inside `bin`. ## Generating it The distribution ships the script, not the keystore. `bin/create-rmi-keystore.sh` is a single `keytool` line: ``` keytool -genkey -keyalg RSA -alias rmi -keystore rmi_keystore.jks \ -storepass changeit -validity 7 -keysize 2048 "$@" ``` The `-alias rmi` and `-storepass changeit` match the property defaults exactly, which is why an untouched `jmeter.properties` works with an untouched script. ## Why the download has no keystore The source tree does contain a `bin/rmi_keystore.jks` for the project's own tests, but the release build excludes it from the binary layout. That is deliberate: a shipped keystore would be a published private key, and every reachable engine on earth would then accept a test plan from anyone who downloaded JMeter. Keeping it out is what turns "SSL on by default" into a real control instead of a formality. ## What the failure actually looks like - If the property is left blank, `RmiUtils` throws immediately with `No keystore for RMI over SSL specified.` and tells you to set `server.rmi.ssl.disable` to `true` if that was intentional. - If the property names a file that does not exist, the store is only opened when a socket is created. The generator fails while exporting its engine object, so `jmeter-server` dies at startup; the controller, whose client factory loads the store inside `createSocket`, fails later, at the registry lookup. - If one node has the file and another does not, or two nodes hold keystores generated separately, the connection fails during the handshake rather than at startup. ## The opt-out `server.rmi.ssl.disable=true` removes the requirement, and it has to be set on **every** node — a mixed fleet cannot negotiate anything. Treat that as a decision about network exposure, not a shortcut, because it also removes the mutual client authentication that keeps an unknown controller from driving your engine. How certificates, key pairs and trust chains work underneath is TLS material and is covered by the dedicated TLS topics; what belongs here is the JMeter property names, the script, and the fact that the file has to exist on every participant before a run can start.