I85PREP
⌘ K
Besu Certified Professional study materials
Besu Certified Professional study resources

Besu Certified Professional: Security, Key Management, and TLS

Besu Certified Professional · Work through your exam, one topic at a time.

All guide sections

Security, Key Management, and TLS

This domain tests protecting keys and endpoints. Besu uses three distinct key types, and confusing them is both a security and an operational failure.

Core rules

  • The node key in the data path determines the enode identity. A validator key signs blocks and must match an address in genesis. Account keys sign transactions and should live in a wallet or HSM, not on the node.
  • Restrict file permissions on key files and keystores; never pass passwords on the command line, use password files instead.
  • Bind RPC to loopback and keep ADMIN, DEBUG and TRACE off externally. Use --host-allowlist and CORS deliberately.
  • Enable TLS for RPC with --rpc-http-tls-enabled plus keystore and password-file options; keystores are PKCS12 or JKS. Mutual TLS uses --rpc-http-tls-client-auth-enabled with a truststore or a known-clients file.
  • The Engine API used by a consensus client is protected by a JWT secret shared with that client, for example via --engine-jwt-secret.
  • Peer-to-peer traffic is encrypted and authenticated by RLPx; there is no separate P2P TLS layer to configure.

Worked example

You expose RPC to a monitoring host. Generate a keystore with keytool, store its password in a file readable only by the Besu user, start Besu with TLS enabled and the keystore and password-file flags, then connect using curl with the CA certificate. If you need client certificates, add mutual TLS and list the monitoring host certificate in the known-clients file.

Traps

  • Exposing 8545 to the internet with default settings.
  • Reusing one key as node, validator and account key.
  • Self-signed certificates without distributing the CA to clients.
  • Leaving the JWT secret world-readable when running a paired consensus client.