Since the invention of SSL back in 1995, it has evolved into a solid foundation for a safe and secure way to transact business over the web. In fact, the most recent incarnation of SSL—now called TLS—has become the most important authentication protocol used in web-based transactions.
The proper use of TLS certificates
SSL/TLS is necessary for two reasons. SSL/TLS security encrypts the data moving between a web server and a browser, making it extremely difficult to intercept and decode the information. However, SSL/TLS security goes beyond mere encryption. The proper use of TLS certificates ensures that the organization which owns the certificate is indeed what it claims to be.
How can parties to the transaction be sure they are communicating with the proper participants? If a customer is trying to purchase an expensive smartphone from an online retailer, the business must be able to confirm its identity to the customer. Otherwise, even if the customer’s credit card information is encrypted when in transit, but the retailer’s web site has been spoofed, all of that encrypted data may be sent to a cyber criminal who can easily decrypt it.
This is where the importance of third-party validation is most apparent. This validation is achieved through trusted root Certificate Authorities (CA) whose business to issue trusted root certificates. These certificates are included in the browsers’ trusted stores. Any TLS certificate that is signed with one of those trusted root’s private key will be trusted by any browser or device using a trust store that includes it. Through the certificate chain of trust, organizations can prove that they are who they say they are. As long as the signatures can be traced back to the root, the end-user certificates can be trusted.
TLS Machine Identity Management for Dummies
Self-signed certificates for internal enterprise environments
Even when business is blossoming, companies always look for ways to reduce costs. Although security is not the first line of defense to trim expenses, some IT professionals believe that they can easily lower budget by eliminating third-party CAs from the equation. So they argue that self-signed SSL/TLS certificates are an acceptable alternative for internal sites. They believe that, since only internal employees have access to servers that host internal-facing sites such as intranet portals and wikis, self-signed certificates provide adequate protection at practically no cost. A self-signed certificate is one that you create in-house, using tools like openssl instead of requesting it from a public CA.
Some professionals argue that with regard to intranets and company networks, self-signed certificates have myriad advantages:
- Private CAs pay for themselves very quickly
- Self-signed certificates can have customized lifecycles
- No fear of third-party revocation
- You aren’t dependent on another company for certificates
- You can automate issuance for Private CAs
Self-signed certificates give you a more granular level of control over encrypting your enterprise environment.
Self-signed Certificates Cost and Security Risks
But this is only one side of the coin. In a great article “The Hidden Costs of Self-Signed Certificates”, Teresa Wingfield argues that “The total cost of ownership (TCO) of an SSL certificate is far more than just the price of the certificate. From security hardware, to management software, to data center space and more, the costs of establishing a secure self-signing architecture can quickly add up.” This is a mission critical issue if you want to ensure that your privately-owned certificates are not compromised.
In Wingfield’s words “Unless keys are stored in hardware, organizations cannot guarantee that it knows how many keys exist and who has had access to them. If the network is compromised, a company has no way of knowing if a key was copied off-site and is being compromised.” In addition, if the malicious actors get your private root certificate, they can conduct man-in-the-middle (MitM) attacks to impersonate banking, e-commerce, and social media websites.
Once compromised, self-signed certificates can pose a number of challenges. If an attacker has gained access to a system, the attacker can spoof the identity of the victim. Here is a major difference between third-party CA certificates and private ones. CAs can revoke a certificate when they discover it has been compromised, but a private one cannot be revoked, just disabled. At best, you may end up with a slew of bad certificates that you’re no longer using but can’t get rid of. At worst you may suffer from an outage caused by an expired certificate that you didn’t even know about and can’t locate. That means you have to be very deliberate about how you use self-signed certificates.
On the security risk issue, IBM Knowledge Center explains that “a user with a self-signed personal certificate might be able to use it to sign other personal certificates. In general, this is not true of personal certificates issued by a CA, and represents a significant exposure.” To prevent this type of compromise, you need to be sure that your internal CA infrastructure is secured as well as that of the best public CAs, you need to have in place robust automated systems available to ensure adherence to strict policies designed to prevent misuse. Replicating this infrastructure to match the high security standards in place at leading CAs requires a number of costly components. And this increases your self-signed certificate infrastructure cost disproportionally.
Self-signed certificate protection
The biggest challenge most enterprises face is managing their certificates. Leading third-party CAs typically offer web-based applications with easy-to-use management interfaces that automate and accelerate many processes, including delegating authority for creating certificates and approving certificates for signing by the CA. But still we have heard and read of many certificate management problems that lead to, for example, expired certificates. The cost of expired certificates is unacceptably high: they will negatively impact customers and internal stakeholders alike.
Tools that allow you to self-sign certificates—such as Microsoft Certificate Authority—do not include certificate management functionality. You need to have in-house processes similar to those of the public CAs, such as full visibility, regular reporting, tracking certificates so that you can make decisions on revoking them or re-issuing for certain end points. In addition you will need to plan and implement robust processes to help ensure that SSL/TLS protocols are being strictly followed.
Teresa Wingfield warns: “Some businesses attempt to automate the SSL security workflow by writing custom software, but many simply attempt to manually manage the processes. This takes a considerable amount of time and effort from highly skilled and trusted staff—which may mean more highly paid senior employees.” Manually managing your certificates is an error prone process, an extremely time consuming task that can take skilled personnel away from other mission-critical work.
The trust issue
When compared with certificates signed by CAs, self-signed certificates are viewed as less trustworthy because they have not been vetted through official channels. Web browsers do not trust self-signed certificates and when users try to access a site “protected” with a self-signed certificate, they will get an error message that says the signing entity is unknown and not trusted. This kind of message scares off potential customers, partners, and other stakeholders. For this reason, few businesses (if none) will use self-sign certificates for external-facing web sites. Retaining user trust is simply too important.
The trust issue brings into discussion another kind of risk. In addition to all the hidden costs an organization may accrue with self-signed certificates, as we have discussed before, it may also face increased operational risks. Although difficult to quantify, these dangers can add up to substantial expenses if not mitigated.
Lack or loss of trust is a serious business risk, that may be intolerable for businesses. Building trust with (external) customers and (internal) end-users is the cornerstone of a successful enterprise. Trust is critical for any web-based transaction, whether it’s online banking or uploading a Social Security Number to an internal employee portal. Although the true value of trust is difficult to quantify, not winning the trust of potential customers could be disastrous to revenues. For an internal site, a lack of trust among employees could impact worker morale and productivity.
Whether or not you decide to include self-signed certificates as part of your strategy for machine identity management, there are certain best practices that you should always follow. Keep track of all certificates across the enterprise. Continually monitor the status and usage of all certificates. Automate the full certificate lifecycle to ensure maximum availability and reliability.
That’s why it is crucial for your organization to employ a certificate management solution to protect your PKIs. Visit venafi.com if you’d like to learn more about how you can simplify machine identity management for all keys and certificates.
Get a 30 Day Free Trial of TLS Protect Cloud, Foolproof Certificate Management.
Related posts
