@Rocky StarRocks FE nodes— does it need a restart when the SSL cert renews?

Yes, a restart of the StarRocks FE nodes is required for SSL certificate renewals to take effect. Based on the documentation and the system's architecture, here is the breakdown: Why a restart is necessary * Static Configuration: SSL parameters such as

ssl_keystore_location

,

ssl_keystore_password

, and

ssl_key_password

are defined in the

fe.conf

file. These are classified as static parameters (non-mutable), meaning they are only loaded once during the FE startup process. * Java SSLContext: The FE is a Java-based process. It initializes its

SSLContext

and the MySQL protocol server (which handles SSL/TLS) at startup. It does not monitor the keystore file for changes on the disk after the process has started. * No Reload Command: Unlike some other databases, StarRocks currently does not have a dedicated SQL command (like

SSL_RELOAD

) to refresh certificates in-memory without a restart. Best Practice for Renewal To minimize downtime during certificate renewal, you should perform a rolling restart of your FE nodes: 1. Update the keystore file on all FE nodes (ensure the path and permissions match what's in

fe.conf

). 2. Restart the Follower FE nodes one by one. 3. Finally, perform a switchover or restart the Leader FE. _ _Tip:* You can use

stop_fe.sh -g

(Graceful Exit) to allow current queries to finish before the node shuts down. Summary of FE SSL Parameters Parameter | Description | Mutable (No Restart)?

ssl_keystore_location

| Path to the

.jks

or keystore file. | No

ssl_keystore_password

| Password for the keystore. | No

ssl_key_password

| Password for the specific key. | No

enable_https

| Enables HTTPS for the FE. | No For the BackEnd (BE) nodes, the behavior is similar; the

ssl_certificate_path

and

ssl_private_key_path

are also static and applied only at startup. References • administration/management/BE_configuration.md • administration/user_privs/ssl_authentication.md • administration/management/FE_configuration.md

@Rocky what is the TLS version used by starrocks?

StarRocks supports secure connections via SSL/TLS, and the protocol version used depends on the component (FE or BE) and the underlying software environment (Java or OpenSSL). 1. Frontend (FE) Nodes The FE is Java-based and handles the MySQL protocol and HTTP connections. * Supported Versions: Typically TLS 1.2 and TLS 1.3. * How it's determined: The FE relies on the Java Secure Socket Extension (JSSE) provider within your JDK. * If you are running on JDK 8, the default is usually TLS 1.2. * If you are running on JDK 11 or later, TLS 1.3 is supported and often preferred. * Configuration: Starting from StarRocks v4.0, you can manage security more granularly using

ssl_cipher_whitelist

and

ssl_cipher_blacklist

in

fe.conf

, though there is currently no dedicated parameter to force a specific protocol version (like

ssl_min_version

). 2. Backend (BE) Nodes The BE is written in C++ and handles internal bRPC communication and Stream Load (HTTPS). * Supported Versions: TLS 1.2 and TLS 1.3. * How it's determined: The BE uses OpenSSL. * Most StarRocks versions (prior to v4.0) bundled OpenSSL 1.1.1, which supports both TLS 1.2 and TLS 1.3. * Connections between nodes and for data loading (starting from v4.0 with

enable_https=true

) will negotiate the highest mutually supported version between the client and server. 3. Client-Side Negotiation Because StarRocks is compatible with the MySQL protocol, the TLS version is also subject to negotiation. * MySQL Clients: Most modern MySQL clients (8.0+) will attempt to negotiate TLS 1.2 or TLS 1.3 by default. * JDBC: The version depends on the JDBC driver and the client's JVM. You can often force a version in the connection string:

jdbc:mysql://<host>:<port>/<db>?enabledTLSProtocols=TLSv1.2,TLSv1.3

Summary Version | Support Level TLS 1.0 / 1.1 | Generally deprecated; supported by older libraries but disabled by default in most modern environments. TLS 1.2 | Default/Standard. Widely supported across all StarRocks versions and JDKs. TLS 1.3 | Supported. Available in FE (requires JDK 11+) and BE (requires OpenSSL 1.1.1+). Recommendation: To ensure you are using the most secure version (TLS 1.3), ensure your FE nodes are running on JDK 17 and your clients are using modern drivers. References • administration/user_privs/ssl_authentication.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md References • administration/user_privs/ssl_authentication.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md

@Rocky is it possible to check cert expiry date?

No, StarRocks does not currently provide a built-in SQL command (like

SHOW CERTIFICATES

) or a specific monitoring metric to check the SSL certificate expiry date. To check the expiry date, you must use standard command-line tools on the server where the certificates are stored. 1. Check Frontend (FE) Certificate Since the FE uses a Java KeyStore (

.jks

), use the

keytool

command. You will need the

ssl_keystore_location

and

ssl_keystore_password

from your

fe.conf

.

bash
keytool -list -v -keystore <path_to_keystore.jks> -storepass <keystore_password>

Look for the "valid from ... until" line in the output. 2. Check Backend (BE) Certificate BE nodes typically use PEM files. You can check the

.crt

or

.pem

file directly using `openssl`:

bash
openssl x509 -in <path_to_be_cert.pem> -noout -dates

Look for the "notAfter" date. 3. Check Over the Network You can also check the certificate currently being served by a running FE or BE node from a remote machine (replace ports as necessary, e.g.,

9030

for FE MySQL port or

8030

for FE HTTP port):

bash
# For FE MySQL Port (9030)
openssl s_client -connect <fe_ip>:9030 -starttls mysql | openssl x509 -noout -dates

# For FE HTTPS Port (default 8443 or 8030 depending on config)
openssl s_client -connect <fe_ip>:8443 | openssl x509 -noout -dates

Monitoring Tip Because StarRocks does not expose this via Prometheus metrics natively, it is a best practice to use an external Prometheus exporter (like the Blackbox Exporter) or a custom script to monitor the TCP/HTTPS ports and alert you when the

probe_ssl_earliest_cert_expiry

threshold is reached. References • administration/user_privs/ssl_authentication.md • administration/management/FE_configuration.md • administration/management/BE_configuration.md References • administration/user_privs/ssl_authentication.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_FRONTENDS.md • faq/operation_maintenance_faq.md • administration/user_privs/authorization/privilege_faq.md

@Rocky how to perform a safe restart of the FE nodes without service disruption post ssl cert renewal?

To perform a safe restart of FE nodes after an SSL certificate renewal without service disruption, you should follow a rolling restart strategy. This ensures that at least two-thirds of your voting FE nodes (in a typical 3-node HA setup) remain active to maintain a quorum. Prerequisites 1. Replace Certificate Files: Ensure the new certificate files (e.g., the

.jks

keystore for FE) are placed in the correct directory on all FE nodes before starting the process. 2. Verify Configuration: Confirm that

fe.conf

points to the correct paths and that the file permissions allow the StarRocks user to read them. ────────── Safe Restart Workflow Always restart Follower FE nodes first and the Leader FE node last. Step 1: Identify the Leader Log into StarRocks via a MySQL client and run:

sql
SHOW FRONTENDS;

Check the

Role

and

IsMaster

(or

Role

=

LEADER

) columns to identify which node is the current Leader. Step 2: Restart Follower Nodes (One by One) On each Follower node: 1. Graceful Shutdown: Use the

-g

flag (available in v3.3+) to notify load balancers and drain active connections.

bash
    ./bin/stop_fe.sh -g

Note: Without

-g

, the node shuts down immediately, which may drop active read queries. 2. Wait: Ensure the node has stopped (

ps aux | grep StarRocksFE

). 3. Start: Restart the node.

bash
    ./bin/start_fe.sh --daemon

4. Verify: Run

SHOW FRONTENDS;

again and ensure the node's

Alive

status is

true

before moving to the next node. Step 3: Restart the Leader Node Once all Followers are updated and healthy: 1. Graceful Shutdown: Run

./bin/stop_fe.sh -g

on the Leader. 2. Automatic Election: The remaining Follower nodes will automatically elect a new Leader. This typically takes a few seconds. During this brief window, write operations (DDL/DML) may pause, but read operations on the other nodes will continue. 3. Start: Restart the old Leader node.

bash
    ./bin/start_fe.sh --daemon

4. Verify: Final check with

SHOW FRONTENDS;

to ensure all nodes are

Alive

and the cluster is stable. ────────── Key Considerations * Load Balancer Integration: If you use a load balancer (like F5 or HAProxy) pointing to the FE MySQL port (9030) or HTTP port (8030), the

stop_fe.sh -g

command makes the FE return

HTTP 500

on its

/api/health

endpoint. Ensure your load balancer is configured to perform health checks so it stops sending traffic to the restarting node. * Write Availability: While restarting Followers, write availability is unaffected. When the Leader restarts, there is a very short interruption (usually <5s) while a new Leader is elected. * Timeout: By default,

stop_fe.sh -g

waits 60 seconds for queries to finish. You can adjust this with

./bin/stop_fe.sh -g --timeout <seconds>

. References • administration/management/graceful_exit.md • deployment/upgrade.md • faq/operation_maintenance_faq.md References • administration/management/graceful_exit.md • faq/operation_maintenance_faq.md • faq/Deploy_faq.md • deployment/upgrade.md • administration/Meta_recovery.md • deployment/deploy_manually.md