All about certificates

Are you one of those managers who doesn't understand when tech people talk about certificates? Are you still calling the CSR a file key? I just met an assistant who does. And her job is to manage certificates. She has been doing this for at least two years, and still, she doesn't know what is the difference between a CSR and a KEY. Time to get things strainght, right now.

The story about certificates is simple. It's all about trust. Start from a real-life example. Imagine you have some gossip to share with a friend. So you meet, you talk, you go home. End of story. What happens when you can't meet? Suppose she is in Finland, and you are in Spain. You can call her, and talk. What if you don't recognize her voice? What if you do know you're talking to her, but can you be sure nobody else is listening? Well, it might not be an important gossip, so you might not even care. What if it was something important and super secret? When it comes to certificates, the questions you need to answer are the following:

• can you be sure you're talking to the intended person?
• can that person be sure, he is talking to you?
• can both of you be sure, that nobody else is listening?
• can both of you be sure, that what is being said hadn't been altered in any way?

These might seem silly in the focus of the previous example. So let's take it a step further. You are willing to wire transfer money to someone. You need to talk to your bank and instruct them to transfer a certain amount to a third party. Now the questions immediately make sense. You are sharing privileged information with your bank, and so does the bank. You need to be exactly sure, that you are talking to your bank, and not someone pretending to be your bank. The bank also needs to be sure that it's you calling them and not somebody else claiming to be you. Otherwise I could just call them saying: I'm John Smith, trust me! But this is not all the story. You probably want to keep it private, how much money you're about to transfer. And last but not least, all involved parties need to make sure that the order to transfer the amount hadn't been tampered with.

Still with me? Certificates are the solution to your problem. They are to help you to authenticate, encrypt and keep integrity of your private messages. Certificates are nothing much but a set of mathematical algorithms and a concept of trust. Let's begin.

Imagine a simple padlock with a key. That same key is used to open and close the padlock. This is what we call symmetrical encryption. In the world of certificates, a key is a password or a passphrase, so the analogy would suggest that the same password / passphrase is used to encrypt or decrypt something. By something we usually mean a given text file. Symmetrical encryption or symmetrical keying is not very complicated. It is secure as long as nobody else has the key. If somebody else obtains the key, the concept is blown away.

Now imagine a more complicated padlock with two keys. The two keys are different. One is only able to close the padlock, but not open it. The other is only able to open it, but not close. What does this mean in the world of certificates? Given a clear text, that you wish to encrypt and send to someone. You need only one key: that is able to encrypt it, so it becomes a cipher text, which the same key is unable to decrypt. You don't possess the other key, so this is the end of the story for you. Now you can only do one thing: send off the encrypted text to the intended person, who has the other key. The one that is only able to decrypt a message. With that, he can decipher the message and understand the contents, but nobody else is capable of doing it. This is called asymmetrical encryption or asymmetrical keying. This refers to the fact that not one, but two keys are required, and those two keys are different from each other.

Note the important bit here. At no time the two keys are needed at the same time. Now, let's look at the certificates more closely. A certificate is a text file that looks greek to the naked eye. It always comes in pair with another text file, called the private key file. Both are a result of a mathematical algorithm. Anyone is capable of generating these two files for himself, for the purpose of being able to receive encrypted messages (that are intended for him), and to provide signed messages, proving that it was him, who created the message. Ahh ha! This is a new function.

Signing something means that you use an algorithm on a plain text message, and producing a hash, that is to certify two things. One: the plain text is created by yourself, as nobody else has your private key, so nobody else could generate the same hash. Two: that message that has the hash has not been altered in any way. In the world of the internet, having a certificate means that you are really who you say you are. But this is not that simple, we're still missing an important point.

If anybody can generate a certificate, claiming who they are - how can one trust the certificates? After all, I could generate one that is proving I'm the Bank of America. Time to introduce the final missing bit into the picture: the Certificate Authority (CA). What do you do when you want to verify someone's identity? You ask for a drivers licence. Why? Because you assume you would be able to tell if a drivers licence is genuine or fake. Therefore who has a genuine ID, has already proven himself to somebody else. To a government agency, for that matter. If that government agency believed that person that he is who he claims to be, and issued a government ID, than this should be enough for you too. See what is happening here? You trust a third party (the government) and accept the photo ID as proof. This is exactly what CAs do. They make damn sure that a person is who he claims to be, and then they create a certificate for them, so they can use that certificate and prove themselves to others.

Now, back to the world of Internet. So, all you need to do is to trust a CA when visiting a webpage that claims to be secure. If the certificate is legit, than the website is too. The only question remaining: how can you trust a CA? Well, the browsers come with a pre-defined list of trustworthy Certificate Authorities. This is one of the reasons you should never trust a browser coming from an unknown source. God knows what altered CA list can be in there. This list of trusted CAs is editable, so you can always control who do you trust.

Now that we know the background, let's see what else we need to know. The life of a certificate begins with a KEY. The key is the secret part, optionally protected by a strong password or passphrase. When you have the key file, the next bit is the CSR, a Certificate Request. This is is a yet-to-be certificate, that isn't signed by anybody. Once you have the CSR, you need to send it to a CA and have it signed. During which the CA verifies your identity, usually asks for money, and then it validates (signes) the CSR. At this point the CSR becomes a CRT, or cert, also known as certificate. The process usually takes a matter of minutes, if it's a low grade certificate, and can take up to days, if it's a high grade certificate. A low grade certificate is when only your e-mail address is verified, or the fact that you are in the posession of a certain domain name. This validation is done by sending a code to an email address, and asking for it back, or it may involve you to create a given hostname within the domain, proving that you are capable of doing so. If it's something serious, like you need the certificate for doing business worth millions of dollars, you're being checked a bit more, you may even be summoned and asked to present photo ID.

One last important bit is left: the validity period. Certificates aren't valid forever. A common interval is one year, usually certificates expire after a year, two years. Some may be available for five years even. CA's certificates are usually valid for a longer time, this is their core business after all. After your certificate has expired, you need to obtain a new one, or re-new the existing one. This is not the only way a certificate can become invalid though. Meet the CRL: Certificate Revocation List. This is a list of revoked certificates. The main reason to revoke one is when they become compromised. A private key may become known to outsiders, which is a perfectly good reason to invalidate a certificate. It's not trustworthy anymore. The CRL is published by the CA on a regular interval and it's your job to check the list when you're accepting a certificate. It's like when buying a car. It's you job to run a HPI check to make sure it's not stolen.

For further information, be sure to check out the OpenSSL webpage (http://openssl.org) which is an open source implementation of the SSL protocol. It is fully capable of creating, signing and revoking certificates. That's it! You are now the master of certificates.