Security

Least privilege

Run clmbot under a dedicated account with exact sudoers and certificate-directory ACLs for Nginx, Apache, Tomcat, and IIS.

Last reviewed: 2026-08-31Language: English

clmbot must read and write target certificate files during an automatic update, then reload or restart middleware. This page describes recommended least-privilege configurations for common middleware.

Before use: These commands are examples, not fixed instructions for every server. Verify the actual account, directory, service name, and command path, then test the configuration outside production.

Least-privilege principles

Run clmbot under a dedicated system account, such as clmbot, and follow these rules:

  • Grant only the access required to read clmbot configuration, logs, and target certificate installation points.
  • Grant write access only to certificate and private-key files managed by clmbot and their containing directories.
  • Allow only reviewed middleware reload or restart commands.
  • Never grant NOPASSWD: ALL or complete root access.
  • Review before_script and after_script manually.

Prohibited configurations

  • Running clmbot permanently as root or Administrator.
  • Opening entire middleware configuration directories, certificate directories, or system-service controls to clmbot.
  • Granting unrestricted execution of bash, powershell.exe, or systemctl.

Middleware permission requirements

Nginx

Required permissions:

  1. Read and write the certificate directory: access the directories containing .crt, .key, and CA-chain files so clmbot can write replacements and create .bak backups.

  2. Run the reload command:

    nginx -t && nginx -s reload

Recommended scope:

  • Open only the target certificate directory, not all of /etc/nginx.
  • Authorize exactly nginx -t and nginx -s reload through sudoers.

Apache HTTP Server

Required permissions:

  1. Read and write the certificate directory: access directories used by SSLCertificateFile, SSLCertificateChainFile, and SSLCertificateKeyFile.

  2. Run the service restart command, depending on the distribution:

    systemctl restart httpd.service

    or:

    systemctl restart apache2.service

Recommended scope:

  • Open only the target certificate directory, not the entire Apache configuration directory.
  • Authorize restart only for the Apache service name used on this host.

Tomcat

Required permissions:

  1. Read and write the certificate directory: access PEM certificate and key files or JKS keystore files.

  2. Run the stop and start scripts:

    export JAVA_HOME="<java_home>" && "<catalina_base>/bin/shutdown.sh" && "<catalina_base>/bin/startup.sh"

Recommended scope:

  • Prefer placing clmbot and Tomcat in the same service group and grant access only to the target keystore or certificate directory.
  • Allow only shutdown.sh and startup.sh for the target Tomcat instance.
  • Do not grant access to all of /opt.
  • Authorize each Tomcat instance separately: give each instance access only to its keystore directory and start/stop scripts. Do not cover every instance with one broad rule.

IIS

The IIS workflow uses a Windows PowerShell script to import PFX and update an HTTPS binding, which requires administrative permissions.

Required permissions:

  1. Run with an administrative account: execute powershell.exe -NoProfile -ExecutionPolicy Bypass to import a temporary PFX and update the IIS site binding.
  2. Read and write the certificate directory: create and remove the temporary PFX file.

Recommended scope:

  • Use a dedicated Windows service account.
  • Grant only the permissions required to manage the target IIS site binding.
  • Review PowerShell execution policy and module permissions against the host security baseline.

Exact Linux sudoers examples

sudoers must allow exact commands, never NOPASSWD: ALL.

Nginx

clmbot ALL=(root) NOPASSWD: /usr/sbin/nginx -t
clmbot ALL=(root) NOPASSWD: /usr/sbin/nginx -s reload

Apache

clmbot ALL=(root) NOPASSWD: /bin/systemctl restart apache2.service

Tomcat

clmbot ALL=(tomcat) NOPASSWD: /opt/apache-tomcat/bin/shutdown.sh
clmbot ALL=(tomcat) NOPASSWD: /opt/apache-tomcat/bin/startup.sh

Certificate-directory ACLs

Set baseline ownership and permissions:

chown -R root:clmbot /etc/ssl/example
chmod 0750 /etc/ssl/example
chmod 0640 /etc/ssl/example/site.crt /etc/ssl/example/ca.crt
chmod 0640 /etc/ssl/example/site.key

Use ACLs for exact write and backup permissions:

setfacl -m u:clmbot:rwx /etc/ssl/example
setfacl -m u:clmbot:rw- /etc/ssl/example/site.crt
setfacl -m u:clmbot:rw- /etc/ssl/example/ca.crt
setfacl -m u:clmbot:rw- /etc/ssl/example/site.key

This allows clmbot to:

  • Write new certificates and private keys.
  • Create .bak backups.
  • Remove backups and temporary files completely.

Pre-deployment permission checklist

  • Is clmbot running under a dedicated account rather than root or Administrator?
  • Can only required accounts read and write config.yaml?
  • Does every certificate file referenced by servers[].format expose only the necessary read and write permissions?
  • Can the certificate directory create and remove .bak files?
  • Have before_script and after_script been reviewed manually?
  • Does sudoers contain only exact commands, with no ALL, shell, or unrestricted systemctl rule?
  • Do Nginx, Apache, and Tomcat reload or restart rules cover only the target instance?
  • Does the Server mode listening address and port comply with firewall policy?

Key concept

The middleware reload or restart command in servers[].after_script is the core permission-management concern. Review all script content manually and authorize each command individually.

Never use NOPASSWD: ALL. It gives the clmbot account complete root privileges and violates least privilege.