We’re not going into the technical details of how the encryption works, as that would become a rather long winded mathematical explanation, but we are going to explain a bit about how SSL certificates play a role in securing Internet traffic. SSL stands for Secure Sockets Layer and is sort of an add-on to an existing system. For example, HTTP traffic is the type of traffic that web browsers use to transfer information from a web server, like the Access Server’s admin UI, to your computer, in the web browser. HTTP by itself is completely unsecured. Anyone intercepting the traffic between your web browser and a web server that uses the HTTP protocol, can see all the pages and texts and information flowing over the network, and can read along with what you’re seeing in your web browser. Obviously that is terribly insecure when you’re visiting a website of a bank or other financial institute. Therefore a security layer is added call SSL. If you apply this to HTTP it becomes HTTPS instead – a secure version of HTTP. With SSL an encryption layer is set up and any traffic flowing over that connection is unreadable to outsiders. This is done using a very clever system using prime numbers and mathematical calculations that make it impossible for anyone trying to intercept the traffic to see what’s going through the encryption connection. Over this encrypted connection, normal HTTP is transferred. But this is only visible and legible to the web server itself, and your web browser. Anyone in between will just see encrypted information, useless to them.
But encryption alone is not the only purpose. Another important purpose is establishing trust. Can you trust that the server you are connecting to, is actually the server that you think it is? For example if you are visiting your bank’s website, how can you be sure that this is actually the bank’s website, and not some other site that cleverly looks a lot like it, but isn’t actually your bank’s website at all? That’s one of the main purposes of SSL certificates – to determine identity of the server and holder of the private key and public key. SSL certificates consist of 2 major components: a private key, and a public key. The private key is generated by the bank itself, and stays with the bank. Nobody else ever gets to see that private key. It is a series of random numbers and letters that has been stored on the web server of the bank and doesn’t ever get shown to anyone else. That is the secret key that nobody else but the bank must know. With this private key, the system administrator of the web server uses a tool like OpenSSL to create a CSR, or Certificate Signing Request. This is a standardized form with a bunch of questions like, what is the address of your website (common name), what are your contact details, where are you located, and so on. Once all these questions are answered a file is generated that is connected to the private key cryptographically, but does not contain the private key itself. The next step is sending this to a certificate authority.
A certificate authority is a company or organization that makes it its business to confirm identity of the owner of a website, and when it has validated this, to take your CSR and sign a new public certificate with their keys. Their keys are special because they are trusted by a root authority. And root authorities are automatically trusted by your web browser or other SSL capable programs. There’s a list in your web browser of known major root certificate authorities and their public keys which are automatically considered trustworthy. Any certificates they sign are trusted as well. Certificates work with a hierarchy: an SSL certificate for your website signed by a certificate authority contains in it information that identifies the certificate that stands above it – in this case the certificate authority that signed your key. And their key also contains information that identifies the certificates above it – all the way up to the root certificate authority key. So it forms a chain from the public key (certificate) they create for your website, all the way to a trusted root authority. Your web browser or other SSL capable program automatically tries to follow this chain and if it ends up at a root authority certificate that is trusted by your computer, then the private key you get is also automatically trusted.
This signed key is a public key that is cryptographically tied to your private key, but does not contain the private key itself. They are inextricably linked. The public key, as the name indicates, is installed on the web server and anyone that visits gets a copy of it. It’s like showing your passport to whomever wants to see it to confirm your identity. But only a trusted authority can issue a passport, and only they know things about you like where you were born, where your live, etcetera, and that you are truly the holder of this passport. Like on a passport, the country and authority that issued it will be mentioned on it. In SSL certificate terms this is the certificate authority that issued you your certificate. Anyone seeing the SSL certificate can check with the authority above it to see if it’s a real certificate.
A neat property of a public-private key pair is that they are linked. If you as a visitor receive the public key, and check it with the certificate authorities above it to see if it’s a real certificate that is trusted by a root authority, then you can do the next test: is the web server showing you this public key also the holder of its linked private key? If not then they’re just faking it. So this needs to be tested. Modern passports can have biometric data integrated into it, like fingerprints and such. Only the real holder of the passport can give their biometric data in a fingerprint test and actually have it match to what is known on the passport. Likewise, anything encrypted using the public key can only be decrypted by the holder of the private key that belongs to this specific public-private key pair. So by simply sending information encrypted with the public key and receiving a sensible response you can be sure that the web server you’re talking to is really the correct web server. After all, only the private key that was used to create the original Certificate Signing Request, which was then approved and signed by a certificate authority and resulted in a public key, can be used to decrypt data encrypted with the linked public key.
So that’s your proof of identity and method of establishing trust. That’s, simplified, how SSL certificates play a role in securing Internet traffic and making sure you are connected to the correct web server.