Runtime Permission Requirements

When clmBot performs automatic certificate renewal, it needs to read and write the target certificate files and reload or restart the corresponding middleware services after the update. This document describes the recommended least-privilege configurations for various middleware scenarios.

Information

The middleware reload / restart commands are defined in the servers[].after_script field of config.yaml, and users can adjust them according to their actual environment. clmBot does not require long-term execution with high-privilege accounts such as root or Administrator.

Least-Privilege Principle

It is recommended to run clmBot with a dedicated system account (such as clmbot):

• Grant this account only the permissions required to read the clmBot configuration, log directories, and target certificate installation points.
• Grant write permissions only to the certificate files, private key files managed by clmBot, and the directories where they are located.
• Allow only confirmed middleware reload / restart commands to be executed. before_script and after_script must be manually audited and authorized one by one.

Not recommended:

• Allow clmBot to run long-term with the root or Administrator identity.
• Grant clmBot full access to the middleware configuration directory, certificate directory, or system service control permissions.
• Grant bash, powershell.exe, systemctl unrestricted execution permissions or NOPASSWD: ALL.

Permission Requirements for Each Middleware

Middleware	Required Permissions	after_script Example
nginx	certificate (.crt), CA chain (optional), private key (.key) files, and read/write permissions on their directories, for writing new certificates and creating .bak backups	nginx -t && nginx -s reload
Apache	Read/write permissions for the directories where SSLCertificateFile, SSLCertificateChainFile, and SSLCertificateKeyFile are located	systemctl restart httpd.service or systemctl restart apache2.service
Tomcat	Read/write permissions for the PEM certificate/private key or JKS keystore files and their directories	JAVA_HOME + shutdown.sh + startup.sh
IIS	The clmBot built-in PowerShell script imports the PFX and updates site bindings, requiring administrator privileges; creation and cleanup of the temporary PFX file	No configuration required; handled automatically by the built-in script

Information

• Scripts automatically generated by the certificate discovery feature use absolute command paths (for example, nginx with the -p and -c parameters, and systemctl uses an absolute path). Refer to the actually generated servers[].after_script instead.
• If Tomcat is managed by systemd, the automatically generated script is systemctl restart <tomcat 服务名> rather than shutdown.sh / startup.sh.

Linux sudoers configuration example

The following example only illustrates the authorization granularity. Adjust the actual paths according to the target host.

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 Permission Example

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

To allow clmBot to write to and back up the above files, you can use ACLs for precise authorization:

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/site.key

Pre-Launch Permission Checklist

Note

Before deploying clmBot, it is recommended to verify the following permission configurations item by item.

• Whether clmBot runs under a dedicated account, rather than root or an administrator account.
• Whether config.yaml allows only necessary accounts to read from and write to it.
• Whether the certificate file pointed to by each servers[].format has only the necessary read/write permissions open.
• Whether the directory containing certificate files allows the creation and cleanup of .bak backup files.
• Whether before_script and after_script have already been manually audited.
• sudoers should contain only exact commands, rather than ALL, bash, or the full systemctl.
• The reload or restart permissions for nginx / Apache / Tomcat should cover only the target instances.
• The service mode (clm-bot server) listening address and port should comply with the host firewall policy.