Main content
Course: Computers and the Internet > Unit 4
Lesson 6: Secure Internet protocolsDigital certificates
The TLS protocol relies on public key encryption. The sending computer uses the public key of the receiving computer when encrypting data. Before that happens, though, TLS requires a step that is crucial to its security: the sender must verify the identity behind the public key.
A digital certificate, also known as a public key certificate or identity certificate, proves the ownership of an encryption key.
The need for certificates
What would happen if TLS did not include a certificate verification step?
Attackers have come up with ways to intercept a request from one computer to another computer on the Internet, such as through rogue access points.
From here, they can launch a man-in-the-middle (MITM) attack. Even though it's called a "man" in the middle attack, attackers come in all ages and genders. You can also think of it as a "masquerader in the middle".
First, during the process of setting up a secure connection with TLS, an attacker sends the client their own public key instead of the server’s public key.
After that, whenever the client encrypts data with the received public key, they're instead encrypting data with the attacker’s public key. The attacker can then decrypt the encrypted message, change it however they'd like, and re-encrypt it with the server’s public key before sending the data to the server.
To prevent a MiTM attack, the client needs to check the identity behind a public key. A digital certificate shows the identity behind a public key. However, if anyone can make them, how can a client trust the legitimacy of a digital certificate? In TLS, clients trust a digital certificate if it was generated by institutions known as certificate authorities.
Certificate authorities
A server that wants to communicate securely over TLS signs up with a certificate authority. The certificate authority verifies their ownership of the domain, signs the certificate with their own name and public key, and provides the signed certificate back to the server.
When the client inspects the certificate, it can see that a certificate authority is vouching for the authenticity of the public key. But it still has a decision to make: does it trust that certificate authority?
Clients generally come bundled with a list of trusted certificate authorities. For example, an Apple iPhone running iOS 10 trusts this list of certificate authorities.
Apple users then have to trust Apple to continually monitor that list to make sure each certificate authority is verifying domains properly.
You can imagine a chain of trust from the user to the server:
At each point, trust can be broken. If the user doesn't trust the client, they can override the client's default list of trusted certificate authorities. If a client no longer trusts a certificate authority, it will remove it from the list. If a certificate authority sees suspicious behavior from a server, it can revoke its certificate.
Intermediate certificate authorities
There are actually multiple levels of certificate authorities: the root certificate authority and intermediate certificate authority.
The root CA does not actually directly issue any digital certificates for servers. It only issues digital certificates for intermediate CAs that act on its behalf. The intermediate CAs can either issue digital certificates for another intermediate CA, or for a server directly.
Thus, there is another chain of trust, from the root CA to the server:
The layers of certificate authorities increase the security of the system. If a root CA discovers that an intermediate CA has been compromised by an attacker, they invalidate the certificates from that CA but continue trusting the certificates from their other intermediate CAs.
🔍 You can see the chain for yourself when you check the certificate for a secured website in the browser. If you click the lock next to the URL, the browser should offer a way to inspect the certificates.
🙋🏽🙋🏻♀️🙋🏿♂️Do you have any questions about this topic? We'd love to answer—just ask in the questions area below!
Want to join the conversation?
What is stopping a Man in the middle from "forging the signature" on these certificates?(26 votes)- Excellent question. One of the requirements of the sign/verify operations in cryptography is to prevent signature forgeries. A common way to achieve this is to "re-interpret" public key encryption (covered in this Online Data Security section).
You can informally view public-key encryption as using two building blocks: make_one_way_hard (i.e. use the private key) and make_reverse_way_easy (i.e. use the public key).
1) In public-key encryption, decrypting an encrypted message is hard without the private key. So, make_one_way_hard corresponds to this decryption. On the other hand, it is easy to encrypt a message with the public key. make_reverse_way_easy corresponds to this encryption. In other words, decryption is one way, and the reverse direction is encryption.
2) For authentication (i.e. sign/verify operations), forging a message is hard without the private key. So, make_one_way_hard corresponds to this sign (e.g. decrypt from (1) ). On the other hand, it is easy to verify a signature with the public key.
Math is often independent of the application. For example, 2x=4 represents a setting where x can correspond to finance (dollars), astronomical(planets), or biological (hair cells) applications. Indeed, the math used for the applications of public-key encryption or signature schemes can look quite similar.
Of course, this is a simplifying analogy, but I hope it provides a new way to think about public-key encryption.(27 votes)
Does not having a certificate mean that the website uses rogue access points?(6 votes)
Hello, Shlok. An access point is merely what is used to access the internet. Websites cannot control what access point you use to access their server, as you could either use the one in your home or the one in the nearest coffee shop :)(10 votes)
- I'm not sure I completely understand what the job of the public and private keys are for when transferring data on the internet(3 votes)
Why does the article say Pacific Daylight Time?(1 vote)
That's when the example certificate depicted in the image at the bottom of the article is said to expire. Because a certificate must expire at an exact, particular time, it is important to note what time zone the time of expiration is written for. Hope this helps!(5 votes)
- What is the difference between tlc tld(2 votes)
- What will happen if the website certificate expires?(2 votes)
- The certificate will simply not be valid anymore. The server will have to get a new certificate from a CA.(1 vote)
- Why does the server include the public key? Cant the attacker see this and use it to decrypt the data?(1 vote)
The public key cannot be used to decrypt data; it is only used to encrypt data and verify signatures created with the corresponding private key.(2 votes)
A digital certificate uses the public key information as a part of the certificate right?
Then doesn't that mean that you could forge a key for a server given that their public key is easily accessible?
If a certificate is public information couldn't a hacker just copy and paste it and use it as their own? Or does it actually have to communicate with a CA server to check for legitimacy every time?(1 vote)- Since private keys are required to sign certificates, an attacker cannot forge certificates with the public key alone. Furthermore, the public key cannot be used to decrypt messages. So, if an attacker pretended they owned a certificate and sent it out to other people, they would not be able to decrypt any messages they received.(2 votes)
What is stopping a Man in the middle from "forging the signature" on these certificates(1 vote)- The client can easily check whether a signature is valid.
Changing any part of the certificate would invalidate the signature and it would be exceedingly difficult to forge a valid digital signature.(1 vote)
can schools https be bad?(1 vote)
