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.
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.