PKI， or Public Key Infrastructure , is the basis of encrypted communication on the Internet, and is a complex field that requires special training to master.
Public Key Infrastructure (PKI) has many changeable parts, which means that there is a great possibility of making mistakes when managing PKI certificates.
Public key infrastructure is the backbone of encryption deployment for most enterprises. A well constructed PKI It can handle a series of responsibilities for your enterprise, whether it is authentication, encryption, or ensuring the integrity of files and e-mail. But PKI is complex. Any company or enterprise may make some common mistakes when managing PKI certificates.
Especially if the scale of the enterprise is not large enough to hire experts to manage its PKI.
Moreover, even if the enterprise has the ability to hire an expert (or even a team), it cannot guarantee that their method is correct. After all, PKI is always developing. As you can see, if you don't keep the forefront of technology, you will make some very serious PKI certificate management errors. Now, we will discuss some common PKI certificate management errors, and what your company can do to avoid these errors.
Let's quickly review the public key infrastructure
Public key infrastructure, or PKI, seems to be a difficult concept to understand at first glance, but once you get it clear, all these are meaningful. PKI includes two aspects: digital certificates and public/private key pairs.
To discuss this, I'll simplify things, but first let's start with the root certificate. The root certificate is at the core of PKI. These digital certificates are generally trusted, and a copy of the digital certificate is saved in the root store of each user's computer system. The root certification authority, the CA that owns one of these trusted roots, can issue certificates from these roots.
When we say issue a certificate, we mean that submit the certificate issuance request to the CA, and then the CA will use its root private key to digitally sign the certificate. Or at least in theory, this is how it works. In fact, the threat of root destruction is so serious that CA has built an intermediate root. An intermediate root is signed by a trusted root, which grants it a trusted state even though it is not part of the root store. Then the CA can issue the certificate by using the private key of the intermediate root to sign the end user or sub certificate.
One more thing, there may be multiple intermediates. Sometimes, the CA will create an intermediate product for itself, or it can issue another intermediate root to the child CA for the child CA to issue from. All of these have created something called an intermediate chain. When the sub certificate is sent to the client, the client will view the digital signature on the certificate and follow this chain to trace back to the certificate signed by the private key. It will continue to read the signature and track the chain until it encounters a root in its trust store. As long as the sub certificate can be linked back to a trusted root, it will be trusted. If not, the client's browser will issue an error warning.
As I just described, from the root CA to the sub certificate, they are all part of the public key infrastructure. stay SSL /In the TLS environment, when the deployment is correct, any client can use the publicly available key to verify the endpoint associated with it, and securely send a symmetric session key for communication.
In short, this is PKI.
Some common PKI certificate management errors
Now let's discuss some of the most common PKI certificate management errors we have seen. We have cooperated with enterprise customers, large companies and small and medium-sized enterprises. All of them have different needs and pain points, but they also have some common problems that almost everyone has encountered.
Although the examples in this article are far from comprehensive, I hope they can help correct all PKI certificate management errors in your enterprise to avoid your PKI deployment problems.
1. Too much time is spent on creating PKI
When you start to create a PKI, suppose you want to complete this task yourself, you will want to develop everything. The reality is that it may be interesting for IT personnel to draw all these boxes and lines. This strange way is almost sexy, and only those who really understand the system architecture can realize it. Unfortunately, we see that the most common PKI certificate management error is that it is too easy to be distracted by other things - worry about your offline root hierarchy, policy/intermediate CA, online issuance CA, etc.
Yes, if you plan to build your own PKI, you need to first establish a real offline root CA, create several intermediate roots from which to sign, and you will also need to use a solid hardware security module (HSM) to protect them. However, there are many other things you need to worry about. These are also important. We'll get to that in a minute.
But first of all, when you draw all these things, you may make everything too complicated. This will only give you a headache, because it will eventually become more expensive and complex. Ideally, a well managed PKI will save your time and stress - not waste your time and increase your stress.
2. Not spending enough time on other configuration details
Although it is easy to spend too much time on the CA hierarchy, we see that another common PKI certificate management error is not spending enough time on other configuration details. This is a mistake, because failing to make the right decision in the setup phase means that if you want to change anything in the future, you must completely redeploy everything.
You may never consider the components of a certificate security policy, and you may not even know what a certificate security policy is, but this should never be a reason to prevent you from defining one. For example, when you use a commercial CA to issue an SSL certificate, you don't have to worry about the certificate revocation list (the CA will be responsible for handling this matter), but if you are creating your own PKI, the responsibility falls on you. Do you need to set one or two OSCP (Online Certificate Status Protocol) servers internally? Do you need one for external use?
As Ted Shorter, CTO of Certified Security Solutions, pointed out:
"PKI has a well-defined structure in terms of policy and practice definition, in the form of certificate policy (CP) and certification practice statement (CPS). These are excellent frameworks for defining different requirements for governance PKI, and can also help to achieve these requirements. Creating these documents may be a difficult task. However, it is important to note that it is not enough to just copy someone else's CP/CPS document set; These tools are only valuable when they truly demonstrate your enterprise's PKI needs and operation process. "
Let's look at some more configured PKI certificate management errors
3. Using outdated algorithms, passwords and protocols
Globally, PKI should have two key attributes: scalability and long-term viability. To get these two points, you need to select the correct configuration. Maybe nothing is more important than choosing passwords and protocols. Public key cryptography is constantly developing, algorithms come and go, and passwords change - if you are not careful, your entire PKI will become obsolete within a few years after its implementation.
This is why it is very important to study and choose the correct algorithm and password. Here are some examples:
- In 2015, SHA-1 was abandoned, and now we use SHA-2. If you chose SHA-1 when you created your own PKI in 2014, you will be in trouble now.
- In August, IETF officially released the TLS 1.3 protocol (RFC 8446). This represents the latest and safest version of the TLS protocol. SSL 2.0, 3.0, and TLS 1.0 should always be disabled. TLS 1.1 is also unwise.
- Soon, the industry will decide whether to continue using RSA asymmetric encryption is still more effective than using elliptic curve encryption technology.
Since Netscape created HTTPS in 1994, cryptography has changed a lot. HTTPS encrypts communication from the SSL (Secure Sockets Layer) protocol. However, the loopholes and defects in the protocol forced the industry to adopt something more secure. After HTTPS was widely adopted, we began to migrate from SSL to TLS (Transport Layer Security). Since then, the TLS protocol has gone through several iterations, from version 1.0 to version 1.3.
This is not the only security change HTTPS has made since its creation. In the past six years, almost all protocols or systems used to protect HTTPS transmission have been damaged or outdated. Here are some best practices for these protocols:
Migrate from SSL to TLS 1.1 or later
- Discard RC4 and use a more secure algorithm
- Use SHA-2
- A key that is too short was used
In PKI, the key is used to encrypt and decrypt information, so an intruder cannot steal the data transmitted between the two parties. PKI is asymmetric encryption, which means that there are public keys and private keys, and the content encrypted by one key must be decrypted by another key. This setting can effectively protect information from prying. In other words, as long as the malicious user cannot obtain the private key, everything is safe.
Hackers can obtain the private key in two ways: stealing it (we will discuss it later), and guessing it. Because these keys are only mathematical algorithms, it is feasible for hackers with enough hardware to reverse the algorithm and determine the basic value. This is not easy, but it is sometimes possible.
The difficulty of guessing (or cracking) a given private key depends on how long the key is and how many bits are needed to store the key. The longer and more complex the key, the more difficult it is to crack. The problem is that with the continuous improvement of technology and methods, it will become easier and easier to guess the private key. Therefore, it is necessary to increase the size and complexity of the key to maintain its security.
In 2002, the 1024 bit key was the absolute minimum for maintaining security. In less than ten years, this minimum value is not enough. 2048 bit keys are now standard, but they will be abandoned at least by 2030. If you use a 1024 bit encryption key, your PKI is very fragile, so you need to update it quickly.
5. Incorrect key size selected
The key is crucial in PKI - even in its name. Keys can be used to encrypt and decrypt data, and they need to be strong enough that no one can guess their value, copy them, or decrypt your encryption. PKI specifically refers to asymmetric encryption (although symmetric encryption also plays a role).
The strength of the key, or its intractability, depends on its length. The longer the key, the more secure it is. For example, the length of a standard RSA private key is 2048 bits. As early as 2002, a 1024 bit key was enough, but today it is no longer enough. In another 10 years, 2048 bit keys may also become obsolete. When things start to get tough, it goes back to our previous point of view, that is, as the asymmetric key becomes longer, its required processing power will grow at an alarming rate, far exceeding the actual key strength. Eventually, we will have to convert the algorithm, because RSA will become very clumsy.
This is a question that needs to be considered. It really needs to be considered.
Ultimately, before making a final decision, you must weigh your security requirements against performance costs and consider all regulatory or compliance requirements.
6. Did not expect that PKI will increase your network traffic
No matter how you configure PKI, it will increase the traffic of your network load. One of the most common mistakes in PKI certificate management is that you forget to consider the impact PKI will have on your enterprise network. How much influence it has depends on your architecture choice. Again, this is something you want to understand at the beginning, not when you finally implement it.
Additional traffic may come from:
1) Certificate issuance
You must consider directory or database requests when querying user details and responses, as well as the bandwidth required when sending any certificate requests to CA. Obviously, this traffic will peak when the certificate is issued for the first time, and any time you need to renew or re issue on a large scale.
2) Use of E-mail
Another application of PKI is e-mail and document signature. If you decide to use this function to deploy PKI, you may rely on additional traffic when sending signed or encrypted e-mail. These mails not only need more bandwidth to send, but also need a directory lookup.
3) Certificate revocation list
As we mentioned earlier, if you have created your own CA, you need to maintain your own CRL. The larger your PKI, the faster your CRL will grow. If every user must regularly download the entire CRL, this will not only increase traffic, but also increase the time required for verification. Of course, this can be eliminated by using OCSP.
4) Directory replication
Depending on how you store certificates, you may see some additional traffic. If you are using LDAP (Lightweight Directory Access Protocol) directories, in larger deployments, these directories will be replicated over the network. Although LDAP is designed and optimized for fast, inexpensive discovery and replication, as well as the correct configuration of it - and makes it well integrated with existing network security policies - it is a challenging task.
7. Certificate and key are not stored securely
Let's discuss another common PKI certificate management error: storing keys and certificates incorrectly. We have been talking about the importance of key security for a long time. There are good reasons for this, because the key disclosure will cause harm to enterprises.
Bruce Schneier is a respected decoder and security researcher. He wrote that security is so important that once you do something badly, you will feel a little guilty:
"In any CA based system, one of the biggest risks is your own private signature key. How do you protect it? Almost certainly, you do not have a secure computing system, and this system includes a variety of protection measures, such as physical access control, shielding devices," air wall "network security, etc; You store your private key on a traditional computer. There, it is vulnerable to viruses and other malicious programs. Even though your private key is secure on your computer, is your computer locked in a room with video surveillance, so you can know that only you have used it? If it is password protected, how difficult is it to guess the password? If your key is stored on the smart card, what is the anti attack capability of the smart card? (Most are very weak). If it is stored on a device that can really resist attacks, will the infected driver computer let a trusted device sign something you don't want to sign?
Although this may make things extreme, if you save the key string in a spreadsheet, place it on a thumb drive or an ordinary hard disk, or even somewhere remotely accessible online, you will make a mistake. Frankly, you should probably use HSM.
However, if you cannot do this, at least make sure that you have fully locked the database or directory you are using. It is also a good idea to restrict access to the keystore to a few senior personnel.
8. Bad certificate lifecycle selection
It's not just a matter of deciding when a certificate expires - although that's a big part of it. If you use your own private CA on your own network, you can issue a certificate according to your own wishes, no matter how long the life cycle of the certificate is.
Certificates with long cycles do not need to be replaced frequently, but with the emergence of new algorithms and passwords, they may eventually become obsolete.
Certificates with shorter cycles need to be replaced more frequently. If you use automation, this will not be a problem. But as we will discuss later, faster key rotation is a good choice for security.
To determine what is best for your enterprise and its PKI, you need to complete it yourself, but you need to develop a complete plan - a signing process - which includes not only the first deployment, but also the entire certificate life cycle.
It is also a good idea to figure out how to handle revocation, key archiving, key recovery and other emergencies.
9. No frequent rotation of keys and PKI certificates
As we just mentioned, it is good to rotate certificates and keys regularly. How long is the issuance and life cycle policy of your enterprise, but it is better to carry out it regularly - once every six months or less is considered the best. If your PKI contains your own private CA, you don't need anything except bandwidth to issue these certificates.
As suggested by Scott Helme, a security researcher, do not wait until the key expires to convert it:
"For 39 months or even 825 days of certificates, what we actually see is that the key is replaced after these periods, rather than within this period. This is a bad habit, because the longer the given encryption key is used, the more likely it is to be attacked. I prefer to use the key that changes rapidly in a short period of time as much as possible, rather than static keys."
"Transient" is a fancy expression for the "session" key. In any case, you can minimize the risk by regularly replacing certificates and keys. Even with some form of attack, certificates and keys will be eliminated within a few weeks.
10. Self signed certificate is used incorrectly
Generally, the key and certificate (which can prove the identity of the website, rather than the digital identifier of the system disguised by hackers) are obtained from a trusted third party named Certificate Authority (CA). However, sometimes, enterprises may also issue their own keys and certificates.
For large enterprises with their own private CAs and large PKIs, it is common to use self signed certificates. In your own network, you can manually add the correct root to the enterprise's trust store, and these self signed certificates also work well (they also apply to the test environment). However, problems arise when these certificates and keys are used externally and provided to end users. Once they are circulated on the market and used for routine use, they will prove to be very dangerous for some reasons.
First, test certificates are usually not as strong as certificates issued by CAs (see the previous section on key length), which makes them easy to be cracked and forged. Second, they are usually not stored securely (more on that later). Third, because they are self signed, when you want to solve the PKI security problem, it is difficult to find them after the fact, so that the vulnerability will lurk in your blind spot.
At least for public oriented attributes, use a trusted CA.
11. Lack of automation
Once an enterprise reaches a certain scale, automation is almost necessary, but even if you don't think you are big enough, it is still an option worth exploring. As with any form of automation, PKI automation can improve efficiency and reduce the possibility of human error. Automation helps renew certificates and keys. It can also track and store data related to certificates and keys, such as:
- How many certificates have been issued?
- What are these certificates for?
- How many keys do we have now?
- Who applied for these keys?
- Who can access them?
Most importantly, automation limits the number of times people actually interact with keys and certificates, thereby reducing human errors. The problem is that few enterprises use automation in their PKI management. This may be because they don't know what automation is, or what it can be used for, or because they don't think it is necessary. The alternative is to let people run the system, but this often leads to unsafe and unreliable practices.
12. Lack of visibility
The last PKI certificate management error we will discuss is also the most dangerous one: lack of visibility of your PKI. Specifically, it is your sub certificate. You need to be able to see all the certificates you have issued, who issued them, and when they will expire - you need a complete inventory accounting.
This is really the only way to prevent rogue certificates -- valid certificates that have been destroyed. If the certificate contains the name of one of your domain names, an attacker may imitate your enterprise and cause various hazards. The focus here is not to go deep into the issue of rogue certificates, but to consolidate our view that we need visibility on the entire PKI. This is a function required to properly manage certificates.
Fortunately, there are many great tools that can help you manage certificates. They come from certificate authorities such as Comodo and DigiCert, as well as world-class third-party security companies such as Venafi. What is most effective for you and your enterprise depends on your own personal situation, but within a certain enterprise scale, if you do not use a certain management tool, you will be derelict - even if you establish it yourself - because these management tools can make you have visibility and control your overall PKI.
Avoid the most common PKI certificate management errors
Designing a PKI is a bit like building a house -- if you want it to be reasonable and reliable in structure, you need to plan it and comply with regulations. As we discussed earlier, when setting up your enterprise's PKI, you may always make some potential PKI certificate management errors, but if I can, perhaps the best suggestions that can cover all of these are only four words:
Don't worry
When you deploy PKI for your enterprise, take your time and don't worry. Make necessary research in formulating correct policies and selecting correct configurations. Make sure to consult with anyone who will become a stakeholder and try to predict whether this will conflict with other network security policies.
take your time.
Don't be afraid to ask for help, because it is very complicated, and sometimes even experts need experts. It is better to find the right people to make the right deployment - a deployment that can be expanded and maintain long-term feasibility - rather than trying to complete all the work locally and make it a mess. In the long run, this will only make you pay more.
