Security

Security

The clmbot security model and trust boundaries, including mTLS, credentials, private keys, log sanitization, checksums, firewall rules, and vulnerability reporting.

Last reviewed: 2026-08-31Language: English

This page explains the clmbot security model, deployment risks, and vulnerability-reporting process.

Security model and trust boundaries

clmbot runs on your server within these trust boundaries:

  • Upstream certificate service such as CaaS, private CLM, or another service: holds certificate-issuance capability and authenticates clmbot according to the upstream implementation.
  • clmbot process: runs under a dedicated system account with access only to required certificate directories and exact service-reload commands. See Least privilege.
  • Target middleware such as Nginx, Apache, Tomcat, or IIS: receives files written by clmbot and is reloaded by after_script.

Important trust assumptions:

  • The upstream is trusted to issue the correct certificate. Connect only to an upstream you trust and can audit.
  • before_script and after_script run with clmbot privileges. Script content is executable code and must be reviewed manually.
  • If the clmbot account is compromised, least-privilege controls should limit the impact to its certificate directories and authorized commands.

Mutual TLS (mTLS)

In Remote push mode, clmbot listens in Server mode, using 8862/TCP in the current example, and supports mutual TLS with the upstream. Both sides validate certificate identity so an unauthorized party cannot push to clmbot or impersonate clmbot to receive a certificate.

Scheduled pull listens on no port. Its outbound connection uses the secure authentication method defined by the upstream.

Credential storage

  • Enter AccessKey, AccessSecret, and similar upstream credentials only during initialization. Do not put them in shell scripts, repositories, CI configuration, or screenshots.
  • Allow only the clmbot account and required administrators to read config.yaml and credential-storage files.
  • Rotate credentials regularly. Revoke and replace them immediately after personnel changes or suspected exposure.
  • Use placeholders such as <YOUR_ACCESS_KEY> in documentation and support requests.

Private-key file permissions

  • Use 0640 or stricter permissions for private keys such as .key, and limit owner and group membership to required accounts.
  • Use 0750 for certificate directories and ACLs for exact clmbot read and write access. See Least privilege for examples.
  • .bak files can contain old private keys. Protect them like active keys and remove them when they are no longer required.

Sanitize configuration and logs

Before sharing config.yaml, update.log, or terminal output in an Issue or support request, remove or replace:

  • AccessKey and AccessSecret.
  • Private keys and PFX passwords.
  • Sensitive fields in config.yaml.
  • Internal IP addresses, hostnames, and customer identifiers.
  • Complete certificate contents.
  • Command history and logs containing credentials.

Download verification and signatures

  • Download clmbot only from the official sslTrus CDN listed on the download page and verify SHA256. See Installation.
  • Do not run a file whose checksum differs.
  • Published SHA256 values are the current release-integrity mechanism. If signatures or provenance are added later, the release notes will document them separately.

Firewall rules for 8862/TCP

  • Scheduled pull requires no inbound port, which is a major reason it is recommended by default.
  • Remote push requires an inbound port, using 8862/TCP in the current example. Allow only trusted upstream source addresses and bind to only the required network interface. See Remote push.

Script execution risk

before_script and after_script run automatically during certificate updates:

  • Anyone who can modify these scripts can execute code with clmbot privileges. Restrict write access to the script files.
  • Review every line before first use and after every change.
  • Do not embed credentials or invoke an unrestricted interpreter. See prohibited configurations in Least privilege.

Report a vulnerability

Do not disclose an unpatched vulnerability in a public Issue, Discussion, forum, or social-media post.

Private reporting channels:

  • Security email: security@clmbot.org.
  • If the GitHub repository Security page shows Report a vulnerability, you may also submit a private report there.

Include the affected version, sanitized reproduction steps, and an impact assessment. Maintainers will first validate the information and coordinate a fix. When users can take action, a security advisory will identify affected releases and upgrade guidance. No fixed response deadline is promised.

Sanitization checklist before a public Issue

  • AccessKey and AccessSecret removed
  • Private keys and PFX passwords removed
  • Sensitive config.yaml fields removed
  • Internal IPs, hostnames, and customer identifiers removed
  • Complete certificate contents removed
  • Command history and logs containing credentials removed