8 Certificate Management Mistakes You Can Avoid
8 Certificate Management Mistakes You Can Avoid
Public Key Infrastructure (PKI) is the backbone for enabling robust encryption implementations. A well-established PKI can manage anything from authentication to encryption to ensuring file and email integrity. PKI is facilitated by digital certificates and public/private key pairs. Managing PKI is a complicated task. Hence, many organizations are making certificate management mistakes that jeopardize the efficiency and effectiveness of the PKI structure.
Here’s a breakdown of the most common certificate management mistakes.
Outdated algorithms, ciphers and protocols
PKI must be scalable and viable. These attributes are enforced by selecting the correct and appropriate cryptographic ciphers and protocols. Public Key Cryptography is constantly evolving, algorithms might become outdated and ciphers change because of technological developments.
- SHA-1 has been deprecated since 2011 and is now completely broken. SHA-2 is the new normal.
- TLS 1.3 is the most recent, most secure version of the TLS protocol with major improvements such as forward secrecy. SSL 2.0, 3.0 and TLS 1.0, 1.1 should never be used. All browser vendors have dropped support.
- Quantum computing will render RSA asymmetric encryption obsolete, and Elliptic Curve Cryptography will gain more attention.
It is therefore critical to research and choose the correct algorithms and ciphers for the PKI implementation.
Wrong key sizes
Keys are critical in PKI. They are used to encrypt and decrypt data, and they need to be adequately robust so nobody can guess their value, copy them, or decipher the encrypted data. Key length defines an algorithm's security since it is “associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system.”
Encryption systems are often grouped into families. Common families include symmetric systems (such as AES or 3TDEA) and asymmetric systems (such as RSA or Diffie-Hellman). As each of these is of a different level of cryptographic complexity, it is usual to have different key sizes for the same level of security, depending upon the algorithm used.
But as technology evolves, keys need to adapt, otherwise, they could break in just a few seconds. For instance, a standard RSA private key is 2,048 bits long. Back in 2002, 1024-bit keys were sufficient, today they’re not. In another ten years, 2048-bit keys will likely be obsolete, too. This where we need to be careful. As asymmetric keys get larger, the processing power required to use them increases at a much greater rate than the actual key strength does.
Before making the final decision, you will need to consider security needs against the performance costs and also factor in any regulatory or compliance requirements.
Insecure certificate and keys storage
Improper storage of keys and certificated can wreak havoc to organizations.
Bruce Schneier wrote about key security and we should pay attention to his words:
“One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don’t own a secure computing system with physical access controls, TEMPEST shielding, “air wall” network security, and other protections; you store your private key on a conventional computer. There, it’s subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it’s protected by a password, how hard is it to guess that password? If your key is stored on a smartcard, how attack-resistant is the card? [Most are very weak.] If it is stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn’t intend to sign?”
I don’t know if this sounds dystopian, but it is a huge mistake not protecting and securing keys and certificates. The best way to do that is by harnessing the features of HSMs.
Unsuitable certificate lifecycle
Determining the suitable certificate lifecycle is critical for managing these certificates. It is far more than having visibility into the expiration date of each certificate. It is about determining revocations, recovery, archival and other related management activities.
The following factors should be drivers for your decision.
- Longer certificates need to be replaced less frequently but can become outdated as new algorithms and ciphers are enforced.
- Shorter certificates need to be replaced more often, which creates a problem only if you are not using an automation solution. Let alone that if they are compromised, the damage is less.
Infrequent key and certificate rotation
Rotating certificates and keys regularly is good practice. How frequently is related to corporate policies. Either way it is advised to rotate at regular intervals, with GDPR suggesting that every six months or less is considered best practice.
Security researcher Scott Helme suggests, don’t wait until expiry to rotate keys:
“This is bad hygiene and the longer a given cryptographic key is in use the more likely it is to face compromise; I’d much rather see a push towards ephemeral keys than static keys wherever possible.”
The use of ephemeral or “session” keys is also a good practice, minimizing risk. Even if there were some sort of compromise, the certificate and key would be obsolete within a few weeks.
Misusing self-signed certificates
For large enterprises, the use of self-signed certificates might be the best choice. But one of the most common certificate management mistakes is organizations using a self-signed certificate on production systems or a public-facing domain. Anyone outside of your organization that tries to access that domain is going to get a connection error, sending the wrong signals about your organization.
Additionally, improperly secured self-signed certificates can be leveraged by cyber-criminals to conduct man-in-the-middle (MitM) attacks to impersonate banking, e-commerce, and social media websites.
Lack of Automation
Automation is no longer a nice-to-have option. It is a necessity, a must-have. As with any form of automation, automating certificate management improves efficiency and reduces the potential for human mistakes. Automation helps with the renewal of certificates and keys. It can also identify and store data related to your certificates and keys like:
- How many certificates does your organization possess?
- What is the purpose of those certificates?
- How many keys are used?
- Who is the owner of these assets?
- Who has access to them?
Without automation, trying to keep information organized across spreadsheets maintained by humans is a source of headaches and nightmares.
Lack of Visibility
Lack of visibility is one of the most serious mistakes. You need to be able to see all the certificates you have issued, who they were issued by when they expire. You need a complete inventory.
This is really the only way you can guard against rogue certificates. Attackers may leverage these compromised certificates to impersonate people and businesses and cause financial and reputational damage. It is only through complete visibility that organizations can minimize the risk of rogue certificates or reduce the outages caused by expired certificates.
How to minimize these mistakes
Designing a public key infrastructure is a little like building a house—if you want it to be structurally sound and dependable, you need to plan it out, and adhere to codes. Like any industry, PKI design has best practices, and to make the infrastructure secure they need to be treated as law.
Centralizing PKI management this way (especially for larger organizations, which may have thousands of certificates to manage) is the only effective way to ensure the security of a given system. Disorganization and lack of accountability only breed vulnerabilities, and it’s only a matter of time before someone (internally or externally) exploits them.
Learn more about how the Venafi TLS Protect machine identity management solution can help with certificate management, to identify weaknesses in the system and build an infrastructure that maintains the privacy of your users.
Related posts
- 5 Questions to Ask About Your PKI Certificate Management
- Management Mayhem, Part 3: How to Avoid the Hidden Costs of Certificate Management
- 4 Misconceptions about PKI that Deserve to be Debunked
- Why Do You Need CA Agility? [100s of Known PKI Incidents]
Like this blog? We think you will love this.
Why Healthcare IoT Requires Strong Machine Identity Management
The rise of IoMT
Read More
About the author
Anastasios Arampatzis
Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years of experience in evaluating cybersecurity and managing IT projects. He works as an informatics instructor at AKMI Educational Institute, while his interests include exploring the human side of cybersecurity.
Read Posts by Author
