In general, security policies are important because they provide protection for your organization. They spell out the rules, expectations, and overall approach your organization uses to maintain the confidentiality, integrity, and availability of your data. Since TLS machine identities, commonly referred to as TLS certificates, are a critical security asset for both authentication and protecting data in transit, it’s critical to have policy that clearly states how they should be created and managed.
When it comes to setting policies for how TLS certificates should be created, NIST, in the Special Publication 1800-16: Securing Web Transactions, TLS Server Certificate Management (SP 1800-16) provides very detailed guidelines. I’d encourage you to read the entire guidelines but will highlight a few recommendations here.
Identify approved Certificate Authorities (CAs)
There are many sources for certificates – Certificate Authorities that offer public-facing certificates (as well as PKI for issuing private certs), private PKI providers like Microsoft and Venafi Zero Touch PKI, open source options like OpenSSL, public cloud providers options and many more. It’s fine for organizations to work with multiple CAs for public-facing certificates and one or more CAs for private certificates for internal networks. In fact, it’s recommended in case one of your CAs is compromised in some way and you need to switch providers.
It is important though to specify which are the approved CAs within your organization and the use cases that they are approved for. Costs can quickly run up if different teams are standing up or paying for their own certificate providers, and if teams are doing their own thing, they might not have the expertise to do so securely. Clearly identifying approved CAs as part of your machine identity policy avoids these issues.
Identify certificate validity periods
The validity period specifies the start date and end date when a TLS certificate can be used. Validity periods vary for different types of certificates. Since September 1, 2020, all publicly trusted TLS certificates must have a lifespan of 398 days or less to be trusted by the major web browsers, such as Google Chrome, Mozilla Firefox, Microsoft Edge and Apple Safari.
Certificates on private networks don’t have the same requirements. You can set them to be valid for as long, or as short as desired or needed. We’ve seen a few cases where certificates on private networks had extremely long validity periods … even decades or longer. A long-lived private certificate might seem attractive in that you might think you never have to worry about it expiring and causing an outage. There are reasons to set a shorter validity timeframe in your machine identity management policy.
The NIST SP 1800-16 guidelines recommend that validity periods for certificates on private networks be one year or less with the main reasoning being to reduce the possible time that a private key, if it was compromised, could be used for malicious purposes. Whatever gets decided, having certificate validity periods documented in your machine identity management policy is important so application owners aren’t left to make their own decisions.
Identity certificate details
There are many, for lack of a better word, “details” that need to be assigned for a TLS certificate. For example, the signing algorithm, key length, and subject DN and SAN contents. These are extremely important to include in a machine identity management policy. Will an average application owner know that it's ok to use RSA 2048 as a key length but not RSA 1024.
Understanding issuing templates in Venafi TLS Protect Cloud
Even with a written policy, it can still be a challenge for certificate owners to follow it when they request certificates. They may not be familiar with the policy or use it that often. That’s why in Venafi TLS Protect Cloud, we’ve made it easy to issue TLS certificates quickly and securely with issuing templates.
An issuing template combines the selection of a CA account with rules that enforce certificate policies, all in a single location. And when you create your issuing template, you define the rules that reflect your company's certificate security policies for requesting or renewing certificates. You can create as many issuing templates as you need, and then edit or delete them at any time.
We created a short video to show how to create and share issuing templates in TLS Protect Cloud.
Security policies are powerful. They help protect our data and assets. A policy for the management of machine identities is also powerful. Defining the processes, roles and responsibilities for those who create and deploy TLS certificates will help ensure they are effectively managed and able to protect machines and machine to machine communication within the organization.
Venafi TLS Protect Cloud, with capabilities like issuing templates, lets you enforce these policies via automation. You can try it for yourself by signing up for a free 30-day TLS Protect Cloud trial.