Certificate update methods

clmBot supports two certificate update methods, which can be selected based on the server network environment:

Update Method	Working Mode	Port Requirements	Applicable Scenarios
Cloud Push	Push initiated from the admin console, received and updated by the clmBot server	Requires opening the 8862/tcp inbound port	Network policies allow it and immediate updates are desired
Scheduled Pull	clmBot periodically checks the cloud for new certificates and updates automatically	No inbound port required	Servers where inbound ports cannot be opened (recommended default method)

The two methods do not conflict with each other. Within the same batch of servers, some can use push while others use scheduled pull.

Method 1: Cloud Push

Start the clmBot server on the server

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

-a Specify the listening address and port, defaulting to 0.0.0.0:8862. After startup, clmBot will run as a server daemon, waiting for pushes from the cloud.

Note

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

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

Information

The clmBot server must remain running to receive pushes. In production environments, it is recommended to register it as a system service and enable startup on boot. See Service Deployment and Upgrade.

Push a Certificate in 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 automatically completes the update.

Method 2: Scheduled Pull

Scheduled pull mode does not require opening an inbound port. clmBot periodically performs update checks, making it the recommended default method.

Linux: Configure crontab

Add the clmBot update command to crontab:

crontab -e

Add a line (run the certificate renewal check at 3:00 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 specify the configuration file path with the -c parameter without changing the directory: ./clm-bot-linux-amd64 -c /opt/clm-bot/config.yaml update-certificate.
• Please replace the path with the actual installation directory.

The execution output is appended to update.log, and clmBot also records runtime logs in logs/clm-bot.log in the directory where the configuration file is located.

Windows: Configure a Scheduled Task

Create a scheduled task on the Windows server to run periodically:

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, select Run to verify, and then check the logs in the installation directory to confirm the execution result.

Automatic Certificate Re-signing and Renewal

The certificates updated by clmBot come from automatic re-signing in the cloud. Log in to the management console, go to the SSL certificate details page, and in the automatic re-signing settings, select or enter the re-signing interval (such as 30 days) and save.

Overall effect after configuration:

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

• When the local certificate matches the latest cloud certificate, the update is skipped.
• When they differ, the local certificate files are automatically backed up (generating a timestamped .bak backup), then before_script, writing the new certificate, and after_script are executed in sequence to complete the service reload.

Tip

If you need to force a after_script without updating the certificate (for example, to debug the reload script), you can use the --force-after parameter.