Digital certificates play a vital security role on the Internet. They allow you to prove that your websites are genuine, sign applications and software updates to prove that they originated from you, and communicate with customers easily using encryption.
The drawback to certificates is that if anything goes wrong, the potential fallout can be disastrous. Criminals can create fraudulent websites that appear to be yours, they can create malware that purports to be software originating from you, and they steal credit card details and other valuable information that customers believe only you can decrypt.
Before looking at what can be done to prevent any of this from happening, it’s worth recapping briefly how certificates work.
How Digital Certificates Work
They start with a root certificate authority, a company which is trusted to issue certificates that certify the sender’s identity. The certificate is signed by the certificate authority using its private key, and anyone can verify the signature using the certificate authority’s public key.
Where do they get that public key? Public keys to trusted authorities are embedded in browsers and other Internet client software, so they should be on any modern computer.
The certificate includes public key infrastructure (PKI) information including a private and public key pair. When installed on your Web server it can supply visitors’ browsers with your public key as well as a list of symmetric ciphers your server supports. The browser can use that public key to send an encrypted message back to you containing a symmetric key to be used to encrypt communication back and forth between you and the visitor’s browser for that session.
You can also use the public key in a certificate to sign software that your organization distributes, so that anyone downloading it from any source on the Internet can verify that it comes from you and has not been altered or had malware added to it. Since the certificate is signed by a certificate authority, anyone can verify that it is genuine.
Certificates have a finite life span — often a year or two — before they expire and are no longer valid. Some people argue that the reason they expire is so owners have to buy new ones, but there is another reason too. Certificates can be revoked, and when this happens their details are added to a certificate revocation list (CRL) which client software checks before accepting them. Certificate expiration dates ensure that CRLs never get too long; once a revoked certificate has expires it no longer needs to appear on a CRL.
Importance of Updates
Problems with certificates can arise in a number of ways. First, a certificate authority can be compromised. If that happens, as was the case with Dutch certificate authority DigiNotar in 2011, hackers may be able to issue malicious certificates that appear to be signed by that certificate authority. Such certificates could be used to falsely “prove” that a website belonged to a bank or any other organization, or it could be used to sign software to “prove” that it came from Microsoft or another reputable software house when it fact it could have been modified to include malware.
Any company that uses certificates issued by a trusted certificate authority is also a potential problem. That’s because if a hacker penetrates that company’s network it may be able to access one or more of its certificates. It can then use that information to build a website that appears to belong to the company, or to create malicious software which is signed as coming from the company.
What can you do to prevent falling victim to a fraudulent certificate from a certificate authority that has been compromised? Unfortunately, there is little you can do to protect your organization directly. Your Internet client software is “hard wired” to trust certificates from trusted certificate authorities unless the certificates or the certificate authority’s root certificate are revoked — usually via a software update — or they expire. That means the certificate will continue to be trusted until the security breach is noticed and the certificate added to a CRL, your browsers are updated or it expires.
The one step you can take is to ensure that all your Internet client software has the latest security updates installed as soon as they become available.
Trust No One
An expired certificate should be worthless, because a browser or other client software will generally warn a user when a certificate that is being presented has expired. But some users may decide to trust an expired certificate because they believe that someone has simply forgotten to renew it, and if it was valid a day or so previously, why shouldn’t it be trusted? This provides an opportunity for hackers.
That’s because trusting an expired certificate ignores risks trusting one that has previously been revoked. But because it has expired it will no longer appear on any CRL. That’s why it’s important that staff understand not to ignore expired certificate warnings, and to stop a transaction or software installation if a certificate has expired — even if only a few hours ago.
Know Your Digital Certificates
If hackers manage to infiltrate a company network, the company’s certificates are likely to be targeted because hackers tend to target an organization’s least well-defended assets. The problem is, many organizations fail to recognize how valuable their certificates are and therefore fail to protect them adequately, according to Jeff Hudson, CEO of certificate and key management software vendor Venafi.
He recounts a story of a retailer that estimated it had 5,000 active certificates within its organization. “In fact, it turned out that they had 20,000. That’s 15,000 more than they thought. Five thousand had no owners, no one knew what they did, what they allowed and who was responsible for them.”
One way this situation can arise is through the use of self-signed certificates. You can download certificate authority software and certify your own certificates for your own use. Many in-house software developers do that instead of buying certificates from a certificate authority, while they develop and test software. This becomes a problem if these self-signed certificates end up being used in a production version of the software. Also, the certificates themselves may simply be stored on the developer’s laptop, unprotected by any security mechanisms.
Another problem is the use of certificates that use the MD5 hashing algorithm. Since 2008 it has been known that MD5 has weaknesses that allow hackers to generate cryptographic tokens or other data that allow them to create forged code-signing certificates. Nonetheless, many organizations unwittingly continue to use them.
“If your organization is confident in knowing how many of these there are, and where they are, and what systems are potentially at risk as a result, then well done,” says Derek Brink, a research fellow at Aberdeen Group. “If not, then the business decisions are the same as always: accept the risk, ignore the risk (which is the same as accepting it), try to assign the risk to someone else, or take steps to understand and mitigate it. Running a comprehensive scan would be a good place to start.”
Digital Certificate Management
The only practical way that organizations can keep track of large numbers of certificates and manage them securely is by using a certificate and key management system, says Brink. Examples of these systems include:
- Venafi
- Entrust Discovery
- Trustwave Certificate Lifecycle Management
- Symantec Certificate Intelligence Center
“For most companies, management of certificates is an under-recognized problem. If you don’t know how many you have, what kind, where they are, when they expire, what systems they are intended to protect, and so on — then you may be ignoring or accepting an unacceptable amount of risk,” says Brink. “Managing the lifecycle of keys and certificates is an essential operational aspect of maintaining effective information security.”
When things go wrong, a management system can also help, he concludes. “The organization relies on the trust in their essential IT infrastructure that is established by certificates and keys — and if that trust is compromised, it needs to be in a position to react and respond quickly.”
Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.
