v3.0.3

• Added the ability to configure expected key usage in a spec file
  Previously a cert was considered invalid if it did not contain the KeyUsage for server authentication.
  You can now add key_usages: [“client auth”] to specify the certificate should be valid for client auth.
  Default behavior has been retained, if you do not specify key_usages it is assumed the cert should be valid for server authentication.
• Fixed a crash encountered when errors were encountered loading a spec.
• Better handling of authentication errors from cfssl.
  Previously we would retry requests unless the token was invalid. Now we do not retry on any authentication failures.
• Fixed bug with certmgr version not showing the actual version info
• Comment fixes (thanks @jbrampton)

v3.0.2

This is a minor release that fixes the output of certmgr version so that the version number is defined when building in travis.

v3.0.1

• Switched to go1.14
• Fixed build scripts
• SIGHUP support for reloading all configurations
• Spec changes now cause warning logs instead of trying to automatically trigger a restart.
• take_actions_only_if_running: true configuration option added, which instructs certmgr to not try to restart a downed service when a new cert is created
• Graceful shutdown support added to prevent certmgr from exiting while writing files
• Splay logic added through configuration variables initial_splay and interval_splay, delaying when certmgr does interval checks. This prevents all of your certmgr instances from waking up at the same time
• SpecLoad and SpecFailure metrics have been removed (they are unused without opportunistic reloading). Remaining spec metrics moved into cert namespace
• Exported metric spec_next_wake_timestamp showing when certmgr will wake up to do its next check
• Dropped spec_watched_total metric, it is redundant
• Major restructuring to split certmgrd internals from certmgr lib code to produce a useful api

v1.6.5: Merge pull request #93 from mkevanz/mkevanz/v1.x/upgrade-prom-client

Upgrade v1.X Prometheus client

certmgr 2.0.1

Changes since 2.0.0 are thus:

• Fix regression for spec's that have an IP as part of the hosts; for certmgr
  2.0.0 would regenerate the spec every interval invalidly. The code now
  properly validates that IP + DNS is the same.

• PKI content on disk now has permissions verified; if the permissions no longer
  match the spec requires- due to OOB changes or the spec being changed while the
  daemon was down- certmgr will trigger a regeneration of that spec.

  If the permissions don't align with what the spec states, we have no way of
  knowing if the service consuming the PKI was able to access the content- thus
  our only option is to trigger a regeneration.

• Certmgr no longer tolerates spec's that have non unique pathways for the CA, Cert,
  or Key files. This is broken client side configuration if 2 spec's specify a shared
  path (or if a spec internally specifies the same path for cert and CA).

  For loads, this is treated as broken configuration, and the startup failed. For
  reloads detected via spec mtime changing, if the new spec conflicts with any paths
  known to certmgr, that spec is rejected and the old is continued to be used.

v2.0.0

certmgr 2.0.0

This release breaks API compatibility with certmgr-1.x and has much more strict
validation logic for what certmgr tolerates.

Specifically:

• certmgr daemon configuration must now be yaml- json is no longer supported.
• Spec's must now define their notification mechanism- actions- fully. If a spec
  lacks svcmgr or action or service- this is fine, it just means nothing is
  notified. If any of those are specified, then the resultant configuration must
  be validly parsed by the svcmgr that is targeted.
• Spec's are now strictly validated; unknown/unsupported fields in a spec is now
  a parse error that will prevent usage of the spec. Typo's will be caught, is the
  short version.

There has been significant enhancement to the handling of on disk PKI since 1.6.4.
Major improvements are thus:

• Ondisk PKI content- CA, cert, key- are all now fully validated. Cert and key are
  checked to confirm they're a valid keypair; cert is checked to confirm it still is
  signed by the current CA. On disk CA is checked to ensure it's the actual remote CA; etc.
  In particular, key algorithm and size are now also validated- certmgr will now detect
  if they're no longer matching the spec and it will force regeneration.
• Via the previous change, mtime checks are no longer relied upon. This- and the above-
  removes the source of all known false positive "force a regeneration" events for
  certmgr.
• Certmgr no longer can trigger two actions for when a CA and cert/key has changed; it
  now only triggers a single action once PKI content is updated for both.
• Certmgr now opportunistically tries to renew cert/key when the CA has changed; the
  goal is to maximize the lifespan of the new content since we already have to trigger
  a notification of the consuming service.

Finally, other major improvements that aren't PKI related:

• yaml is now properly supported for spec definitions. It's much more human readable,
  thus it's our recommendation to use that format if at all possible.
• metrics were rewritten in full. Each spec now has basic metrics exported indicated
  expiry time, event counts for maintainance of the spec, failure counts, etc. It
  should be possible to now have sane operational monitoring of certmgr, including
  alerting.
• certmgr now longer has a permission race for content it writes to disk- previous
  versions had a small window where the PKI content could have the certmgr user as the
  owner, rather than the specified user. All PKI content is now atomically renamed into
  place, thus this window is gone.
• Initial steps were taken towards structured logging for certmgr; it's now possible
  to enable json logging if desired. Future certmgr releases will improve the internal
  logging to be more structure orientated.

v2.0.0-rc0: certmgr 2.0.0-rc0

This release breaks API compatibility with certmgr-1.x and has much more strict
validation logic for what certmgr tolerates.

Specifically:
* certmgr daemon configuration must now be yaml- json is no longer supported.
* Spec's must now define their notification mechanism- actions- fully.  If a spec
  lacks `svcmgr` or `action` or `service`- this is fine, it just means nothing is
  notified.  If any of those are specified, then the resultant configuration *must*
  be validly parsed by the svcmgr that is targeted.
* Spec's are now strictly validated; unknown/unsupported fields in a spec is now
  a parse error that will prevent usage of the spec.  Typo's will be caught, is the
  short version.

There has been significant enhancement to the handling of on disk PKI since 1.6.4.
Major improvements are thus:
* Ondisk PKI content- CA, cert, key- are all now fully validated.  Cert and key are
  checked to confirm they're a valid keypair; cert is checked to confirm it still is
  signed by the current CA. On disk CA is checked to ensure it's the actual remote CA; etc.
  In particular, key algorithm and size are now also validated- certmgr will now detect
  if they're no longer matching the spec and it will force regeneration.
* Via the previous change, mtime checks are no longer relied upon.  This- and the above-
  removes the source of all known false positive "force a regeneration" events for
  certmgr.
* Certmgr no longer can trigger two actions for when a CA and cert/key has changed; it
  now only triggers a single action once PKI content is updated for both.
* Certmgr now opportunistically tries to renew cert/key when the CA has changed; the
  goal is to maximize the lifespan of the new content since we already have to trigger
  a notification of the consuming service.

Finally, other major improvements that aren't PKI related:
* yaml is now properly supported for spec definitions.  It's much more human readable,
  thus it's our recommendation to use that format if at all possible.
* metrics were rewritten in full.  Each spec now has basic metrics exported indicated
  expiry time, event counts for maintainance of the spec, failure counts, etc.  It
  should be possible to now have sane operational monitoring of certmgr, including
  alerting.
* certmgr now longer has a permission race for content it writes to disk- previous
  versions had a small window where the PKI content could have the certmgr user as the
  owner, rather than the specified user.  All PKI content is now atomically renamed into
  place, thus this window is gone.
* Initial steps were taken towards structured logging for certmgr; it's now possible
  to enable json logging if desired.  Future certmgr releases will improve the internal
  logging to be more structure orientated.

v1.6.4

This is a bugfix release that users are advised to upgrade if running 1.6.1, 1.6.2, or 1.6.2.

See 8f8c98a for particulars; when the remote CA changes, certmgr doesn't internally maintain state correctly and will invoke the spec's 'action' on every wake.

v1.6.3

Merge pull request #57 from ferringb/master

Add debug statement for command svcmgr, add `ensure --forceRegen`, cut v1.6.3

v1.6.2

Merge pull request #56 from ferringb/master

Release 1.6.2.