[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.
- 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.
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:
This posting is provided “AS IS” with no warranties, and confers no rights.