Additional notes

The following are additional notes for the Sectigo SaltStack integration.

Filename requirements

The integration package contains sample pillar config files for SSL and client certificates: sectigo_ssl_certificate.sls and sectigo_client_certificate.sls, respectively. You must configure all your SCM and certificate-related parameters in the applicable .sls file prior to running the preceding command. If a new pillar config file is added, make sure that the new file names and the YAML header inside the new file are the same (see the screenshot). You must also make sure to add the new file names into the /srv/pillar/top.sls file.

SaltStack Sectigo filename requirements

Issuing certificates using runners for multiple minion wildcards

It is possible to execute the salt-run command several times for different target wildcards. For instance, suppose that you are using the same master to generate certificates for two different set of minions (APP1-Minion1, APP1-Minion2, APP1-Minion3) and (APP2-Minion1, APP2- Minion2, APP2-Minion3) with the sectigo_ssl_cert_file_path parameter set to /etc/ssl/.

If you execute the salt-run command for the APP1* and APP2* wildcards, the first execution will issue a certificate and store it at /srv/salt/files/certs/APP1_allMinions/etc/ssl/. The second execution will issue a certificate and store it at /srv/salt/files/certs/APP2_allMinions/etc/ssl/. After that, you can use the PUSH or PULL mechanisms to transfer the generated certificates to your applicable minion nodes. This behavior is illustrated in the following diagram.

SaltStack Sectigo using runners