Recommendations for PKI Key Lengths and Validity Periods with Configuration Manager

Recommendations for PKI Key Lengths and Validity Periods with Configuration Manager

  • Comments 8
  • Likes

[Today's post is provided by Carol Bailey]

I sometimes get questions from customers about values to set for the key sizes and validity periods for the certificates required for native mode and out of band management in Configuration Manager.  This has been a tough one for me to answer, because in the main, these values are external to Configuration Manager and they are PKI design questions with advantages and disadvantages for different values.  The higher the key size, the more secure the certificate is from attackers, but will require more processing to use.  The longer the validity period, the less certificate maintenance required (and potentially some service disruption), but the certificate is more vulnerable to being compromised.

Disclaimer:  The PKI-related information in this post is external to Configuration Manager, so you will not find this information in the Configuration Manager product documentation.  However, we realize that PKI is often new to Configuration Manager admins, and aim to share our knowledge and experience to help you be more successful with the product.

Until recently, the best advice I could offer customers without their own PKI consultants, was to follow the example of Microsoft default values on certificate templates that closely matched their own certificates.  Then check any certificate requirements in our documentation (for example, some certificates have a maximum supported key size), and take into account any overheads associated with renewal.  

However, at MMS in Vegas this year, Chris Adams and Ben Shy from Microsoft presented an excellent breakout session that shared their experience about how they implemented native mode and Internet-based client management in Microsoft.  This session was called "Demystifying Native Mode Security to Deliver Internet-based Client Management" and one slide I was particularly keen that they shared with customers was their strategy for deciding the key size and validity period.  Their numbers are based on RSA research and how long it would take an attacker to compromise a certificate.  So the higher the key size, the more secure the certificate is (but remember that this comes at the cost of extra processing). Their simple matrix that they presented at MMS looked like this:

  • Key length of 1024:  Validity period = not greater than 6-12 months
  • Key length of 2048:  Validity period = not greater than 2 years
  • Key length of 4096:  Validity period = not greater than 16 years

When you are deciding which values to use, we've already noted that you need to take into account any other restrictions - such as maximum supported key size by the application that uses the certificate.  However, you also need to take into account what your CA hierarchy can support. A CA cannot issue a certificate with a longer validity period than its own certificate.  This one is easy to remember, however, there's also a ticking time limit because a CA cannot issue certificates with a validity period that is longer than its own remaining validity period.

This means that ideally, you want to plan your validity periods very carefully when designing your PKI - taking into account factors such as the type of certificates that you want to use, the applications that will use them, your company's tolerance to security risks, and your renewal strategy.  However, in practice, you might have to fit your validity periods around your existing PKI design.  

Some examples:

  • If you want to use a validity period of 10 years for your site server signing certificate, this will not be possible if your issuing CA has a certificate with a validity period of 5 years.
  • If your issuing CA has a validity period of 5 years but has been up and running for 2 years, it will not be able to deploy certificates with a validity period of 4 years - until its own certificate is renewed.

More information:

For MMS customers who couldn't attend the session in person, unfortunately a recording of the session is not available but you can view the slide deck.  Search the MMS catalog by code (SY23) or keyword "Internet-based".

There are numerous articles that help to explain how validity periods are used and configured, but I found this one to be a very useful starting point: Renewing a certification authority.

For any key size limitations applicable to the certificates used in native mode and out of band management:


--Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • In case you missed them, the following posts were published on the System Center Configuration Manager

  • <p> </p> ...

  • Just in case you missed it, Carol Bailey has posted yet another fantastic article on certificates over

  • Je relaye ici un article de l’équipe produit SCCM concernant les recommandations et autres best practices

  • This is very good news was well informed that the followers of the issue I am. Thank you ...

  • Introducing such a topic you'd like to congratulate you've let us know. Have good work.

  • This and similar information-sharing my vocabulary expanded again. Thank you for your writing ...

  • The most interesting part of this article is the link to the RSA research on estimate time-to-crack for various RSA key lengths, but this link no longer points to the article in question. The problem of appropriately setting expiry times is terribly under-discussed and yet there are many drivers in systems that push it one way and another. Having this data would make the question "how long should my validity period be" a lot easier to answer convincingly.

    If I claim that our certs need to expire every 2 years, I will be asked how I calculated that. I will be asked whether the calculation includes changes in computing power over time and what those estimates are. I can't just say "Chris and Ben at Microsoft recommend 2 years", especially when I'm confronting people with sound commercial reasons to make it much longer.