Certificate Update Methods

clmBot supports two certificate update methods, allowing you to choose based on the server's network environment:

Update method	Working mode	Port requirement	Applicable scenario
Cloud push	Initiated from the admin console; clmBot receives and applies the update	Inbound port 8862/tcp must be open	Network policy permits it and immediate update is desired
Scheduled pull	clmBot runs periodically via crontab or Windows Task Scheduler to check for updates	No inbound port required	Servers where inbound ports cannot be opened (recommended default)

The two methods do not conflict. Within the same batch of servers, you can use push for some and scheduled pull for others.

Method 1: Cloud Push

Start the clmBot service on the server

./clm-bot-linux-amd64 server -a="0.0.0.0:8862"

-a specifies the listening address and port, defaulting to 0.0.0.0:8862. Once started, clmBot runs as a resident server, waiting for cloud push notifications.

Note

• You need to open the inbound port for 8862/tcp in the server firewall and cloud security group.
• The clmBot server enables mutual TLS authentication for cloud push connections, accepting only push certificates from nodes that have completed onboarding and activation.

If you prefer not to open an inbound port, use Method 2: Scheduled Pull.

Info

The clmBot server must remain running to receive push notifications. For production environments, it is recommended to register it as a system service and enable auto-start on boot. See Service Deployment and Upgrade.

Pushing Certificates from the Admin Console

Log in to the admin console, go to the installation point list, find the target installation point, and click Push Certificate. After confirmation, the system pushes the latest certificate to the server and completes the update automatically.

Method 2: Scheduled Pull

Scheduled pull mode does not require opening an inbound port and is the recommended default approach. clmBot does not include a periodic scheduler, so you need to use crontab, Windows Task Scheduler, or an existing scheduling system to run the update command periodically.

Linux: Configuring crontab

Add the clmBot update command to crontab:

crontab -e

Add a line (run certificate update check at 3 AM every day):

0 3 * * * cd /opt/clm-bot && ./clm-bot-linux-amd64 update-certificate >> update.log 2>&1

Note

• In the command, you must first cd to the clmBot installation directory before executing, because clmBot reads config.yaml from the current directory by default.
• Alternatively, you can stay in the current directory and specify the configuration file path using the -c parameter: ./clm-bot-linux-amd64 -c /opt/clm-bot/config.yaml update-certificate.
• Please replace the path with the actual installation directory.

The command output will be appended to update.log, and clmBot will also record operation logs in logs/clm-bot.log within the directory where the configuration file is located.

Windows: Configure Scheduled Tasks

Create a scheduled task on the Windows server to execute at regular intervals:

cd /d C:\clm-bot && clm-bot-windows-amd64.exe update-certificate >> update.log 2>&1

After creation is complete, you can right-click the task and select Run to verify, then check the log in the installation directory to confirm the execution result.

Certificate Automatic Re-signing and Renewal

The certificates updated by clmBot come from cloud-side automatic re-signing. Log in to the admin console, go to the SSL certificate details page, choose or enter the re-signing period (e.g., 30 days) in the automatic re-signing settings, and save.

The overall effect after configuration:

1. Before the certificate expires, the cloud automatically completes re-signing according to the re-signing period, generating a new certificate.
2. clmBot retrieves the new certificate using the configured method (push or scheduled pull).
3. clmBot updates the local certificate:

• If the local certificate matches the latest cloud certificate, the update is skipped.
• If it does not match, clmBot attempts to create a timestamped .bak backup, then executes before_script, writes the new certificate, and runs after_script. If backup fails, an error is recorded but the update continues; whether the service has fully reloaded should be confirmed based on the script results and middleware status.

Tip

If you need to force execute after_script without updating the certificate (e.g., for debugging the reload script), you can use the --force-after parameter.