Partager via

LINUX Certificate Enrollment and Automated Renewal Using NDES !v2

  • Article

I am periodically asked about a “version 2.0” of my post on “LINUX Certificate Enrollment and Automated Renewal Using NDES”. I continue to watch the development of CERTMONGER.  While promising, the project development hasn’t gotten to a point exactly meets needs outlined in my example scenario.

Rather than do a 2.0 post for now, I have updated the original post with details that have changed.  Let’s cover a few things that have changed and more detail into the lack of a 2.0 post.

SCEP RFC

The SCEP RFC continues to evolve.  It had gone years without an update but now receives regular updates.  Security is the primary driver as the industry adjusts to the deprecation of SHA1.

To support the changes, the Open Source community has continued to update the SSCEP client.

Since my original post, the client now supports requesting SHA2 based certificates.

CERTMONGER READY?

"The certmonger daemon monitors certificates for impending expiration, and can optionally refresh soon-to-be-expired certificates with the help of a CA. If told to, it can drive the entire enrollment process from key generation through enrollment and refresh." (FreeIPA, https://www.freeipa.org/page/Certmonger)

From a features set perspective, certmonger has many capabilities beyond SSCEP making it more flexible.  However, there continue to be two key limitations:

  • Certmonger does not appear to have a provision for downloading a CA chain. That task is left up to the system administrator.  A SSCEP / Certmonger solution would fill that gap as the getca command does that for you.  Neither solution actually adds the import the CA chain to the system CA trust chain.  This must be done separately  (See my other post for automating this).

  • Certmonger has issues with multi-tiered Windows based CA hierarchies.    For many orgs, this can be a deal breaker.  Having a single tier online CA works fine.  Per many threads and my testing, having a two tier hierarchy (offline root / online Windows based NDES issuing CA) will result in a failed request in the monitored queue :

     status: CA_UNREACHABLE
ca-error: Error: failed to verify signature on server response.
stuck: no

The leading indicator is that the client is unable to validate the CA chain for the server response.

 

PATH FORWARD

As the products evolve, I periodically look for ways to improve the process.  In the mean time I will continue to update the original post / example solution until the need for a 2.0 post.