[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:
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.