Configuration and updates

Configuration

The common clmbot configuration model for config.yaml, upstreams, and scripts, plus a CaaS login example.

Last reviewed: 2026-08-31Language: English

A clmbot upstream can be sslTrus CaaS, a private CLM, or another certificate service. This page has two parts:

  1. Common configuration: the local clmbot model that does not depend on a specific upstream.
  2. CaaS upstream example: the login connection workflow for CaaS.

The CaaS login workflow, Endpoint, AccessKey, and AccessSecret apply only to a CaaS upstream. Private CLM platforms and other certificate services require their own adapters; do not reuse the CaaS credential workflow.

Common configuration

The config.yaml file

The main clmbot configuration file is config.yaml in the runtime directory. Generate it with Certificate discovery where possible, then review and adjust it manually.

Key fields include:

  • servers[]: an array of server configurations, with one item for each certificate installation point.
    • format: the certificate format, such as PEM or JKS.
    • before_script: a script that runs before certificate replacement.
    • after_script: a script that runs afterward, usually to reload a service.

See the configuration reference for common fields and commands. For fields introduced by a particular release or adapter, use configuration generated by that same release and its corresponding documentation.

before_script and after_script

clmbot executes these scripts under its runtime account:

  • before_script: preparation before an update, such as stopping a process or temporarily moving traffic.
  • after_script: activating the new certificate, such as nginx -s reload or restarting Tomcat.

Review every script manually before enabling it. Grant reload commands through exact sudoers rules. Never use NOPASSWD: ALL. See Least privilege.

Configuration file permissions

config.yaml may contain sensitive information, including upstream addresses, credential references, and script paths. Allow only the required accounts to read or write it. See Security for credential-storage guidance.

CaaS upstream example

The following workflow comes from CaaS documentation and applies only when CaaS is the upstream.

1. Initialize login

Run this command from the clmbot directory:

./clm-bot-linux-amd64 login

Enter the following values when prompted:

  • Endpoint: the connection address supplied by CaaS.
  • AccessKey: <YOUR_ACCESS_KEY>.
  • AccessSecret: <YOUR_ACCESS_SECRET>.

Obtain credentials from the CaaS management console. Do not put them in a script repository, screenshot, or public Issue.

2. Activate the node

After login initialization, open the CaaS management panel and activate the node. clmbot can synchronize certificates only after activation.

3. Discover certificates and generate configuration

./clm-bot-linux-amd64 discover-certificate

After you confirm the scan results, the command generates config.yaml and registers the certificates with the upstream. See Certificate discovery.

4. Configure automatic certificate reissuance in CaaS

  1. Open the CaaS management console.
  2. Open the SSL certificate details tab.
  3. Set the automatic reissuance period.

By default, CaaS reissues a certificate 15 days before expiration, and this value can be customized. Combine it with Scheduled pull so clmbot can replace the certificate and reload the service after reissuance.

You can also review the clmBot configuration guide (in Chinese) for the detailed CaaS management-console and clmBot node steps.

Independent upstreams

clmbot can adapt to a private CLM or another certificate service. Authentication, configuration fields, and triggering behavior vary by upstream. For production, use only adapters documented for the current release. You may request an unlisted upstream in the Ideas category of GitHub Discussions and include official API documentation and test conditions.

Next steps