Hello,

At the moment I use this formula to distribute cert+private key to servers needing it (web servers...) and that works.
But I wonder if this formula works on Debian to distribute public certificates (like custom CA certificate).

The formula put the cert in /etc/ssl/certs/ and run 'update-ca-certificates', but the normal workflow in Debian is to put the certificate in /usr/local/share/ca-certificates and then run 'update-ca-certificates' (see #7).

I have done some tests and I pretty sure it doesn't work for this usage.

I'm not sure if distribution of root certs is in the scope of this formula, but I think it is, and if not I think it should :)

Has anyone tried this use? Am I missing something?

This formula doesn't offer a way to remove certificates and keys. I'll have a pull request to add in this functionality, however I was curious if there was any preference for doing this. I can do it one of two ways.

1. Create an "absent" state, put the contents of init.sls into a "present" state and have init.sls include the "absent" state, then the "present" state
2. Same as 1, except replacing init.sls with a "managed" state.

I would go with option 2, personally

@daks Is there a plan for using this in a subsequent test suite?

It would be nice if there was an option to deploy new CA certificates.

On at least Debian based distros, CA certificates can be placed inside /usr/local/share/ca-certificates/ named with the .crt extension, and added to the global trusted CA /etc/ssl/certs/ca-certificates.crt using the following command:

update-ca-certificates

Could we please make public cert directory on the saltmaster configurable or move it to salt://files/cert? [1]
The majority of the formulas store files under files/ directory.

[1] https://github.com/saltstack-formulas/cert-formula/blob/master/cert/init.sls#L31

Your setup

Formula commit hash / release tag

Master @ ef33d4d

Versions reports (master & minion)

Salt Version:
Salt: 3003

Pillar / config used

None/Empty

Bug details

If the cert state is called (default) and there is no certs in the pillar cert-updated-system-cmd.run will fail because onchanges::sls::cert.deployed.files didn't render to anything (no state).

Steps to reproduce the bug

With no content in cert::certlist in pillar do:

salt-call --state-verbose=false state.sls cert

Result:

local:
----------
          ID: cert-updated-system-cmd.run
    Function: cmd.run
        Name: update-ca-certificates --fresh
      Result: False
     Comment: The following requisites were not found:
                                 onchanges:
                                     sls: cert.deployed.files
--cut---

Expected behaviour

No action, No error

Attempts to fix the bug

Fixed by adding nop state to head of deployed/files.sls. Patch inbound

Additional context

Perhaps related to #29

Is your feature request related to a problem?

The Red Hat family OSes do not use ca-certificates to bundle certificates but ca-trust.

Certificates must be placed under another directory.

Describe the solution you'd like

Modify the configuration for Red Hat family OS to put certificates and keys under the directories used by ca-trust.

Describe alternatives you've considered

Additional context

When deploying on Debian, if you need to depends on the state ID which deploy the certificate, you need a watch (or equivalent) like this:

 - watch:
    - file: /usr/local/share/ca-certificates/<cert>.crt

but it fails because the generated state ID is /usr/local/share/ca-certificates//<cert>.crt (note the double slash) which is not intuitive.

(Ref #12)

The formula adds the .key extension to key files, but not the .crt extension to cert files. Putting the cert files in the /usr/local/share/ca-certificates/ on Debian family systems and running the update-ca-certificates command will not pick up the certificate without the .crt extension.

This will break backwards compatibility with previous versions of the formula that install certificates, but will be less confusing in the long run to append the .crt extension to certificates being installed.

Currently the cert-formula requires certificates to reside in a salt:// location.

I have a use-case where I want to have both the certificate and key in Pillar data. I think thge formula should support this option as well.