Certificates are used everyday by our computers. They function similarly to our ID cards providing proof of who we are supported by technology that weeds out fakes. Certificates are the way computers and servers announce who they are and establish trust between the connection and target. It allows us to know that we are connecting to the server we intended to and not to an impostor. It also allows us to seal files in their current state – like important documents in pdf form – indicating that they are not to be tampered with. Certificates can be used by rendering software to detect tampering and display a warning that the file is no longer legitimate.
You can very easily create your own certificate. This is best done on a Linux machine with OpenSSL, but any computer with OpenSSL will do. Looking up just about any guide on how to create a self signed certificate via your preferred search engine will lead you in the right direction. Excellent! You have your certificate! And it works, too! You can now install it to your computer’s certificate manager and use it to digitally sign a file. Now your program will recognize the certificate as trusted.
But what if you sent the same file to a friend? Well, it wouldn’t work. Your friend’s PC doesn’t recognize the certificate. This is similar to the problem of paper money in the early days of banks. Paper notes from one bank may not be taken by other banks due to lack of trust. In our scenario, your friend would need to install your certificate in order for their pc to trust the file. This would need to happen for every person you give your file to because the programs trying to run the verifications (the file hashes) don’t recognize the certificate. I’m sure you’re thinking this sounds like a very cumbersome process. What if there was a way to have people trust your file without having to manually distribute your specific certificate? This is the purpose of the Certificate Authority.
Certificate Authorities, or CA for short, operate on the same concept as government issued IDs. Because of the trust in the government that produces the ID, other parties will accept your ID as proof of your identity. When a certificate is signed with the backing of a CA, you can be assured that other people who receive your files or connect to your server will do so without problems. CA chains are typically between 256 and 4096 characters in length in order to spread out the trust levels and speed up the process of issuing certificates and protecting the root certificate. If the root CA is ever exposed, the entire chain and everyone who depends on it is now compromised and must be thrown out.
Having to make certificate signing requests (CSR) against the root certificate all the time also exposes the root certificate. The more offline it is, the more secure it will be. To alleviate this potential issue we rely on intermediate certificates to make our CSR’s against. Most CA’s set the backer of their certificates against government issued certificates and most computers come with a set of root and intermediate certificates that are marked as trusted. This is why you can connect to most websites without having to install any certificates after installing your Operating System.
Some of you may be asking yourself, well how does a certificate do what it does? How do programs verify a certificate? We can start with a basic concept: file hashing. The first example of a hash that I came across in my actual work experience came during a time when I was doing an upgrade on our reporting software. The client I was working with asked if the downloaded files I needed from the software company had a hash that could be verified. I had no clue what he was talking about, but upon further investigation, the answer was a resounding yes! The picture below shows the hash information available from the software company’s download site.
This is when I first learned how security minded companies can verify that downloaded files are legitimate and secure. For further information and a much more technical deep dive on how that hash value can be used, howtogeek.com has an excellent article.
Certificates operate on a similar principle – that the signature on the file or request created via the private key can be verified via the hash and the public key. Public keys are like the seals and special effects on your ID card. Anyone can see them and use them to verify the ID is legitimate. The private key is like the method to create those seals and special effects. Only select people or entities can create it and have access to the method. You do not want that secret method to become public. Similarly, you never want your private keys exposed.
This is what also keeps your browsing safe and secure. When you go to ‘chase.com’, you trust that you are connecting and interacting with the Chase Bank servers. If we were to operate only on faith it would lead to man-in-the-middle attacks where someone’s website ‘posing’ as Chase would intercept and send information to your browser giving a false and potentially dangerous appearance of communicating directly with the Chase Bank servers. Now when you connect to certain websites you should see a lock symbol typically on the left side of the address bar. This is where you can see your browser telling you if you are in fact connecting to the correct website and servers and not a fake copy of the site.
Wrapping Up
The internet wouldn’t be able to function as it does without certificates. Anything involving personal information would be highly risky to use as malicious actors could intercept your data as it travels between the servers and you. This is why the indicators on your browser that the certificate checks passed are so important, and also why you should appreciate that your browser stops you from connecting to a page when there is a certificate error. As you develop your applications incorporate certificates as a means of providing your users with a secure experience. And if you have questions as you do so don’t hesitate to reach out to the Elevate Team.
Authors: Jeff Sugden, Heber Lemus
Leave a Reply