I am doing an assignment where I must design a client-server model for a gas station. Without the digital certificate part, what happens would be:
Initially, I create a database in MySQL which has 3 things: card type (debit/credit), card number, and card status (true/false or valid/invalid).
The client inserts his card, indicates it is a debit or credit and the number of the card.
The server checks the card against what it has in the database. If the type along with the number matches and the status is valid, it allows the client to proceed to choose the gas and so on.
But now with the digital certificate coming in, the instructor wants me to generate a certificate for the client side and the server side. The server will keep its digital certificate together with the CA public key from the CA. The client also save its digital certificate the public key of the CA and save it. The client and server exchanges the digital certificate. Each side verify the digital signature using the CA’s public key. I am a little bit confused of how to design this. I can generate a digital certificate for each side, but then does a new certificate get generated on the client side each time someone puts a card in? I was thinking since the server needs to verify the users of the gas station rather the the client side itself. Or the client and server verifying each other?
Related
In the beginning of an SSL query, the client sends a CLIENT_HELLO message.
The server replies with a certificate message that gives the chain of verifications going back to a known trusted agent.
Suppose for efficiency I wanted to store certificates locally for a new protocol. The current design in TLS is always to require getting the certificate. What could happen to a certificate that would require me to know?
I am trying to understand possible attack scenarios. Consider doing online banking, and suppose a certificate has been compromised. In such as case, the bank is not criminal, but they have been hacked and have to issue a new certificate. Is this reasonable?
If you consider that the bank itself is corrupt, then it seems to me there is no point in worrying about the certificate since they have your money and can just steal it. If the entity you are dealing with goes criminal, does the certificate matter?
Under what circumstances can certfiicates be revoked? I am trying to understand why SSL sends the certificate each time -- it seems really wasteful, but there is probably a good reason.
Would it be possible instead to keep all certificates stored on the client, but check a timestamp with a trusted server? It seems like one could at least send less data across the network
TLS Certificate message after `ServerHello is mandatory in mostly cases, so caching won't have any useful effect. See RFC5246
7.4.2. Server Certificate
When this message will be sent:
The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message.
TLS has its own methods to improve performance. When client sends a valid session_id in ClientHello the session can be resumed and the parties must proceed directly to the Finished messages
Also RFC5077 specifies how to resume sessions without server-side state
EDITED - added comments to specific questions
Suppose for efficiency I wanted to store certificates locally for a new protocol. The current design in TLS is always to require getting the certificate. What could happen to a certificate that would require me to know?
"always" is not correct. TLS sends certificates during handshake. Once the shared key is negotiated, the session can be resumed later by client using sessionid (the usual behaviour). Then, the server does not send the certification chain.
The server sends the certification chain. The client must verify that the presented certificate is reliable:
checking a digital signature performed with the private key of the server certificat
the certificate is issued by a trusted CA. Is supposed that client has a trust store with the root certificates of the certification authorities it trust. The client builds the certification chain presented by server until it finds the root certificate in local truststore
You can perfectly skip the sending of certificates from the server in the second step step if client has a copy of the server certificate in a local truststore
I am trying to understand possible attack scenarios. Consider doing online banking, and suppose a certificate has been compromised. In such as case, the bank is not criminal, but they have been hacked and have to issue a new certificate. Is this reasonable?
In this scenario the attacker could make a MITM attack. The certificate must be revoked by CA and client should check revocation. This is out of scope of TLS
If you consider that the bank itself is corrupt, then it seems to me there is no point in worrying about the certificate since they have your money and can just steal it. If the entity you are dealing with goes criminal, does the certificate matter?
Seems in this case the certificate is the least of the problems...
Under what circumstances can certfiicates be revoked?
Each CA stablish its own procedure. There is no a standard but there are "good practices": When certificate data changes (e.g email) or becomes invalid (Representative of a company), after a renewal revoke the older one, when key is compromised or certificate is lost
Would it be possible instead to keep all certificates stored on the client, but check a timestamp with a trusted server?
Yes it is possible as commented above: Verify a digital signature, verify revocation and stablish a refreshing mechanism
But if you're looking for performance comparing with TLS, the session resumption will probably have better results
I have some basic questions on certificates. Let me first explain my understanding on SSL authentication.
SSL/TLS basically has two main things,
Authentication - to make sure we are communicating to the correct party on both end.
Encryption - encrypt the actual data transferred between both end.
Certificates have the public key and some additional information. SSL communication between Client (say 'C') and Server (say 'S') works like this,
C initiates the request to S.
S sends its public key to C.
C verifies the identity of S. (Server identity verification or server authentication)
C sends its public key to S.
S verifies the identity of C. (Client identity verification or client authentication)
C generates symmetric or session key (say 'K') and encrypt it with S public key and send it to the server.
Now both C and S have the shared symmetric key which will be used for encrypting the data.
Here I believe steps 4 and 5 meant for Client Authentication is optional. Correct me If I am wrong.
Steps 1 to 5 involves asymmetric mode of encryption i.e only for 'Authentication' and after that it involves symmetric mode of encryption for actual data transfer between them.
My questions are as follows,
I have read from this link (related to IIS server) that there are two types of Certificates. One is client certificate and the other is server certificate. I thought the one in the client side who initiates the request is client certificate and the other is server certificate. What is the difference between client and server certificate w.r.to OpenSSL ?. Is there any difference in CN name in these certificates w.r.to OpenSSL ?
I was asked to use Client Certificates for authentication. Does it mean that we are bypassing server authentication and using only client certificates for authentication ?. I don't think so. As per my understanding, client authentication should be done in addition to the server authentication. Correct me if I am wrong here.
Server Certificates:
Server Certificates are identitiy of a Server to presented by it during SSL handshake.
Typically they are issued by a certificate authority (CA) well known to client, The basis on which the certificate is issued is possession of some publicly known Identifier of that server, for Webserver its the Hostname of the server, which is used to reach server
Example:- http://blog.8zero2.in/
Server certifictae
Server Certificates Purpose
clearly mention by the x509 extension parameter
Certificate Key usage
1. Signing
2. Key Encipherment
Signing :- It means that the key in the certificate can be used to prove the Identity of the server mentioned in the CN of the cerificate , that is entity Authentication .
Key Encipherment :- It means the key in the in the ceritificate can be used to encrypt the session key ( symmetic key ) derived for the session
Client Certificate :-
Client certificates as the name indicates are used to identify a client or a user.
They are meant for authenticating the client to the server.
Purpose of holding a client certificate varies
It may represent possession of email address or Mac-address , usually mapped to the serial number of the certificate
Client Certificates Purpose
clearly mention by the x509 extension parameter
Certificate Key usage
1. Signing
1) The article you link is a good one :-). To put it another way: there is a field in the certificate that says what use(s) it is allowed to be used for. When you create/request a certificate, you are asking for a certificate for a particular use, and the CA signs it on that basis.
It is more secure to use different certificates for different purposes and to ensure that each certificate can only be used for its intended purpose. (Or if you want to be cynical, CAs make you buy separate client and server certs so they get more sales.)
For instance, you might want your web server to be able to identify itself as your company for serving purposes, but not want that same certificate to be able to be used to sign outgoing connections to other businesses.
2) You are correct.
I am tring to figure out how a secure connection between client and server is established. I tried the SSL example provided by boost::asio library. My question is about the certifacte used by client and server. To be specific, I generated a private key(mykey.pem). Then I used this private key to generate a self-signed certificate(mycert.pem) and I used these files as follow:
Server side:
1)context_.use_certificate_chain_file("mycert.pem", error);
context_.use_private_key_file("mykey.pem", boost::asio::ssl::context::pem, error);
context_.use_tmp_dh_file("dHParam.pem",error);
Client side:
2)ctx.load_verify_file("mycert.pem",error);
With this code the handshake is done perfectly. My question is that how come both the server and client use the same certificate ("mycert.pem") in commands 1 and 2? With this approach a client can pretend to be a server easily.right? Do you think that I missed something here?
The certificate is public information.
It's the private key that allows the entity to prove its identity. The client is guaranteed by the SSL/TLS handshake that only the party with the private key matching the public key in the server certificate can be at the other end with the suitable master secret, so as to be able to decipher the communication. The problem it addresses is whether or not the remote party is indeed the one to which the certificate was issued. (This is similar to checking that the picture on the photo ID matches the person in front of you.)
Configuration of the certificate (and not the private key) on the client side is there to tell it which certificates you are willing to trust. The problem it addresses is whether or not to trust what the certificate say (in particular what it says about the identity of the server). This is normally done using a PKI, so as to build trust via 3rd parties (the CAs). (This is similar to checking that the photo ID itself is genuine, and that you can trust what it says.)
What you've done by trusting this specific server certificate is bypass the use of CAs to make an exception and indicate you were willing to trust this particular certificate to be genuine. (This is fine for a handful of certificates, but using a CA allows your trust structure to be more manageable and add other features, such as the ability to revoke certificates.)
Recently, I have stumbled upon the basic understanding about PKI work-in-action process. I have looked at major articles about the principles but still I feel quite dumb to understand this process. I understand that PKI is not for „My blog„ but for the sake of simplicity lets walk through simple example “My e-Shop” (for example apache and php) and simple concepts. I wrote some statements that might be vague or even wrong but that’s what I want to know about the process of PKI:
“My e-Shop” as a company needs to be “certified” at some third party CA. That means I need to buy some kind of 1 year membership at that CA, and then, they will register “My e-Shop” at their systems and issue me some stuff like a certificate and a pair of unique public and private keys. Will I get some certificate-file?
Issued certificate is filled with my info and public key and stored in some file at my webserver. The certificate verifies that “My e-shop” is not a bureau of thieves.
Every time users access “My e-shop” through “https” their browsers “silently” checks the presented certificate of “My e-shop” with the one that is registered at CA.
What about users? Do their browsers generate local public+private keys when entering “My e-shop” via https?
When some user enters “My e-shop” via https the following happens: “My e-shop” (webserver) gets the public key (PK1) of the user. The server silently presents the certificate of “My e-shop” to the user, so the users gets the public key (PK2) of “My e-shop”. After some silent checking the browser of the user validates presented certiticate and a secure pipe is established.
When a user sends a request via secure pipe the requests is encrypted with public key of “My e-shop”. Then, web server decrypts the request with its private key. Then, web server sends encrypted response with a public key of the user. At the end, the browser of the user decrypts the response with his private key.
Taking these question by question:
(1) “My e-Shop” as a company needs to be
“certified” at some third party CA.
That means I need to buy some kind of
1 year membership at that CA, and
then, they will register “My e-Shop”
at their systems and issue me some
stuff like a certificate and a pair
of unique public and private keys.
Will I get some certificate-file?
Yes. Also, this varies from CA to CA - some CAs, a 1 year membership and a valid credit card is enough (not to hard to get, even if you happen to be a band of theives), some CAs require a certain amount of paperwork to verify that you are who you say you are. A CA is only as good as it's customer-verification process, so generally the more onerous the process, the better (and more expensive) the CA.
When you have paid your money and done your paperwork, then you and the CA will generate at least 2 things:
A public/private key pair. Often this is generated by YOU, not by the CA. The quality of how you have generated and stored your key pair is also a factor in determining how much another entity can trust your website. Generally, for identification certificates (like SSL server certs) it's a good idea to have the customer (My e-Shop) generate the key.
You'll send a certificate request in a standard format (example: PKCS10) to the CA. It will include a bunch of information about My e-Shop and the public key.
The CA company will check your paperwork and make sure you are you. Then it will use it's CA to digitally sign a certificate for you. That certificate has a bunch of the information you just provided, some extra info that the CA provider sets for you, your public key and the digital signature generated by cryptographically binding all the aforementioned data with the CA's private key.
You get back one of two things:
just the certificate (if you generated your own key pair)
the certificate and the key pair - if the CA generated the key pair for you
(2) Issued certificate is filled with my
info and public key and stored in
some file at my webserver. The
certificate verifies that “My
e-shop” is not a bureau of thieves.
yes... sort of. Your webserver will need both the signed certificate AND the key pair. The key pair is used as part of the SSL handshake to the end user, and that exchange proves that you are in posession of the key pair, and not some band of theives that got their hands on the certificate. This is why you want to protect the key pair.
(3) Every time users access “My e-shop”
through “https” their browsers
“silently” checks the presented
certificate of “My e-shop” with the
one that is registered at CA.
For some definition of "silent". A baseline browser checks that the certificate:
- is currently valid
- is signed by a CA that the browser trusts (or it either denies access or gives you an annoying popup)
Browser add ons will go farther and do things like full path checking (all the way to the self signed root) and certificate status checking. The higher the risk of the info being shared over the pipe, the more checking needs to happen.
(4) When some user enters “My e-shop”
via https the following happens: “My
e-shop” (webserver) gets the public
key (PK1) of the user. The server
silently presents the certificate of
“My e-shop” to the user, so the
users gets the public key (PK2) of
“My e-shop”. After some silent
checking the browser of the user
validates presented certiticate and
a secure pipe is established.
What about users? Do their browsers generate local public+private keys when entering “My e-shop” via https?
OK - stuff is going off the rails here.
For details, check the SSL protocol - the handshake section will give you the hard facts.
The browser and the webserver do pass back and forth information that lets them create a session encryption key. The browser does generate some starting material used to set up the session, but it is not "the public key of the user (PK1)". The user does not need to have PKI credentials UNLESS the server has been configured for client authentication. In a regular, run of the mill My e-Shop, the server has a PKI credential, the browser is generating some key material on the fly for just that one session. The server has absolutely no idea who the browser user is, SSL-wise - all of the user identification comes from a password or something else at the application level.
NOTE: This is for a regular commercial transaction. The higher the risk, the greater the protection. High risk transactions frequently require client authentication.
(5) When a user sends a request via
secure pipe the requests is
encrypted with public key of “My
e-shop”. Then, web server decrypts
the request with its private key.
Then, web server sends encrypted
response with a public key of the
user. At the end, the browser of the
user decrypts the response with his
private key.
Not quite. This is the weeds - a developer of a web application is relatively abstracted from all of this. But - the session content is not encrypted with asymmetric keys - that would be excruciatingly CPU intensive. The PKI of the server and the on-the-fly browser generated handshake data are used to exchange the session encryption key. Part of this is that the client selects and sends a secret key encrypted in the server's public key. Since only the server has the private key, only the server can decrypt the data sent by the client.
This secret key is symmetric (exactly which algorithm is also part of the handshake) and is used for the remainder of the session.
Your steps are incorrect on a couple of different levels. Let me restate them, hopefully in a clear manner.
Your site needs to have an SSL certificate from a trusted third-party CA (Verisign, etc.). You will need to purchase it from them. You will generate the public/private key pair, provide them with your public key (it is part of the certificate request) and they will generate the certificate.
The certificate contains the domain name of your site, your public key, and some other additional information. It does not verify anything, particularly not that your site isn't "a bureau of thieves". All it typically certifies is that you own the domain name for which you are requesting a certificate. It does not mean that your site is trustworthy by any means.
When a user accesses your site via HTTPS, your server will send the certificate down to the client's browser. At no time does the client communicate with the CA to validate your certificate.
3.1. Typically, end users (clients, customers) would not need their own certificates and private keys. This is called mutually-authenticated SSL, and involves both parties (your customers and your site) having a certificate. This is rarely (if ever) used in e-commerce sites.
When a user accesses your site via HTTPS, your server sends down the certificate to the client browser. The client will use this to perform an SSL Handshake. This handshake between the browser and your site is what establishes the secure tunnel. The specifics of the handshake protocol are more technical than you need.
When a request is sent to the server over the SSL tunnel, the server handles it the same way it would any other request. The only difference is that the communication between your customers and your server is encrypted. Your webserver will likely handle the decryption of the data from the request and present it to your webserver for processing. Likewise, the response data is returned back to the client in an encrypted form via the SSL Tunnel.
Better?
Regarding point 3:
As far as I know this is not completely correct. Since there is not really a kind of established live testing infrastructure (in comparison to services like DNS), the web server will send the complete chain of certificates to the browser.
On the other hand the browser or operating system is delivered with a set of trusted root certificates (which need to be updated sometimes, windows update, new browser releases, etc.)
And yes the browser will be supposed to generate an "untrusted" key pair, since under normal circumstances a standard user will not generate his or her own certificate.
Regarding point 5:
Also this is not completely the truth. Computation of asynchronous encryption requires a great amount of time. So the RSA algorithm is just used to exchange keys for faster synchronous encryption standards (i.e. AES, 3TES).
How does SSL work?
Where is the certificate installed on the client (or browser?) and the server (or web server?)?
How does the trust/encryption/authentication process start when you enter the URL into the browser and get the page from the server?
How does the HTTPS protocol recognize the certificate? Why can't HTTP work with certificates when it is the certificates which do all the trust/encryption/authentication work?
Note: I wrote my original answer very hastily, but since then, this has turned into a fairly popular question/answer, so I have expanded it a bit and made it more precise.
TLS Capabilities
"SSL" is the name that is most often used to refer to this protocol, but SSL specifically refers to the proprietary protocol designed by Netscape in the mid 90's. "TLS" is an IETF standard that is based on SSL, so I will use TLS in my answer. These days, the odds are that nearly all of your secure connections on the web are really using TLS, not SSL.
TLS has several capabilities:
Encrypt your application layer data. (In your case, the application layer protocol is HTTP.)
Authenticate the server to the client.
Authenticate the client to the server.
#1 and #2 are very common. #3 is less common. You seem to be focusing on #2, so I'll explain that part.
Authentication
A server authenticates itself to a client using a certificate. A certificate is a blob of data[1] that contains information about a website:
Domain name
Public key
The company that owns it
When it was issued
When it expires
Who issued it
Etc.
You can achieve confidentiality (#1 above) by using the public key included in the certificate to encrypt messages that can only be decrypted by the corresponding private key, which should be stored safely on that server.[2] Let's call this key pair KP1, so that we won't get confused later on. You can also verify that the domain name on the certificate matches the site you're visiting (#2 above).
But what if an adversary could modify packets sent to and from the server, and what if that adversary modified the certificate you were presented with and inserted their own public key or changed any other important details? If that happened, the adversary could intercept and modify any messages that you thought were securely encrypted.
To prevent this very attack, the certificate is cryptographically signed by somebody else's private key in such a way that the signature can be verified by anybody who has the corresponding public key. Let's call this key pair KP2, to make it clear that these are not the same keys that the server is using.
Certificate Authorities
So who created KP2? Who signed the certificate?
Oversimplifying a bit, a certificate authority creates KP2, and they sell the service of using their private key to sign certificates for other organizations. For example, I create a certificate and I pay a company like Verisign to sign it with their private key.[3] Since nobody but Verisign has access to this private key, none of us can forge this signature.
And how would I personally get ahold of the public key in KP2 in order to verify that signature?
Well we've already seen that a certificate can hold a public key — and computer scientists love recursion — so why not put the KP2 public key into a certificate and distribute it that way? This sounds a little crazy at first, but in fact that's exactly how it works. Continuing with the Verisign example, Verisign produces a certificate that includes information about who they are, what types of things they are allowed to sign (other certificates), and their public key.
Now if I have a copy of that Verisign certificate, I can use that to validate the signature on the server certificate for the website I want to visit. Easy, right?!
Well, not so fast. I had to get the Verisign certificate from somewhere. What if somebody spoofs the Verisign certificate and puts their own public key in there? Then they can forge the signature on the server's certificate, and we're right back where we started: a man-in-the-middle attack.
Certificate Chains
Continuing to think recursively, we could of course introduce a third certificate and a third key pair (KP3) and use that to sign the Verisign certifcate. We call this a certificate chain: each certificate in the chain is used to verify the next certificate. Hopefully you can already see that this recursive approach is just turtles/certificates all the way down. Where does it stop?
Since we can't create an infinite number of certificates, the certificate chain obviously has to stop somewhere, and that's done by including a certificate in the chain that is self-signed.
I'll pause for a moment while you pick up the pieces of brain matter from your head exploding. Self-signed?!
Yes, at the end of the certificate chain (a.k.a. the "root"), there will be a certificate that uses it's own keypair to sign itself. This eliminates the infinite recursion problem, but it doesn't fix the authentication problem. Anybody can create a self-signed certificate that says anything on it, just like I can create a fake Princeton diploma that says I triple majored in politics, theoretical physics, and applied butt-kicking and then sign my own name at the bottom.
The [somewhat unexciting] solution to this problem is just to pick some set of self-signed certificates that you explicitly trust. For example, I might say, "I trust this Verisign self-signed certificate."
With that explicit trust in place, now I can validate the entire certificate chain. No matter how many certificates there are in the chain, I can validate each signature all the way down to the root. When I get to the root, I can check whether that root certificate is one that I explicitly trust. If so, then I can trust the entire chain.
Conferred Trust
Authentication in TLS uses a system of conferred trust. If I want to hire an auto mechanic, I may not trust any random mechanic that I find. But maybe my friend vouches for a particular mechanic. Since I trust my friend, then I can trust that mechanic.
When you buy a computer or download a browser, it comes with a few hundred root certificates that it explicitly trusts.[4] The companies that own and operate those certificates can confer that trust to other organizations by signing their certificates.
This is far from a perfect system. Some times a CA may issue a certificate erroneously. In those cases, the certificate may need to be revoked. Revocation is tricky since the issued certificate will always be cryptographically correct; an out-of-band protocol is necessary to find out which previously valid certificates have been revoked. In practice, some of these protocols aren't very secure, and many browsers don't check them anyway.
Sometimes an entire CA is compromised. For example, if you were to break into Verisign and steal their root signing key, then you could spoof any certificate in the world. Notice that this doesn't just affect Verisign customers: even if my certificate is signed by Thawte (a competitor to Verisign), that doesn't matter. My certificate can still be forged using the compromised signing key from Verisign.
This isn't just theoretical. It has happened in the wild. DigiNotar was famously hacked and subsequently went bankrupt. Comodo was also hacked, but inexplicably they remain in business to this day.
Even when CAs aren't directly compromised, there are other threats in this system. For example, a government use legal coercion to compel a CA to sign a forged certificate. Your employer may install their own CA certificate on your employee computer. In these various cases, traffic that you expect to be "secure" is actually completely visible/modifiable to the organization that controls that certificate.
Some replacements have been suggested, including Convergence, TACK, and DANE.
Endnotes
[1] TLS certificate data is formatted according to the X.509 standard. X.509 is based on ASN.1 ("Abstract Syntax Notation #1"), which means that it is not a binary data format. Therefore, X.509 must be encoded to a binary format. DER and PEM are the two most common encodings that I know of.
[2] In practice, the protocol actually switches over to a symmetric cipher, but that's a detail that's not relevant to your question.
[3] Presumable, the CA actually validates who you are before signing your certificate. If they didn't do that, then I could just create a certificate for google.com and ask a CA to sign it. With that certificiate, I could man-in-the-middle any "secure" connection to google.com. Therefore, the validation step is a very important factor in the operation of a CA. Unfortunately, it's not very clear how rigorous this validation process is at the hundreds of CAs around the world.
[4] See Mozilla's list of trusted CAs.
HTTPS is combination of HTTP and SSL(Secure Socket Layer) to provide encrypted communication between client (browser) and web server (application is hosted here).
Why is it needed?
HTTPS encrypts data that is transmitted from browser to server over the network. So, no one can sniff the data during transmission.
How HTTPS connection is established between browser and web server?
Browser tries to connect to the https://payment.com.
payment.com server sends a certificate to the browser. This certificate includes payment.com server's public key, and some evidence that this public key actually belongs to payment.com.
Browser verifies the certificate to confirm that it has the proper public key for payment.com.
Browser chooses a random new symmetric key K to use for its connection to payment.com server. It encrypts K under payment.com public key.
payment.com decrypts K using its private key. Now both browser and the payment server know K, but no one else does.
Anytime browser wants to send something to payment.com, it encrypts it under K; the payment.com server decrypts it upon receipt. Anytime the payment.com server wants to send something to your browser, it encrypts it under K.
This flow can be represented by the following diagram:
I have written a small blog post which discusses the process briefly. Please feel free to take a look.
SSL Handshake
A small snippet from the same is as follows:
"Client makes a request to the server over HTTPS. Server sends a copy of its SSL certificate + public key. After verifying the identity of the server with its local trusted CA store, client generates a secret session key, encrypts it using the server's public key and sends it. Server decrypts the secret session key using its private key and sends an acknowledgment to the client. Secure channel established."
Mehaase has explained it in details already. I will add my 2 cents to this series. I have many blogposts revolving around SSL handshake and certificates. While most of this revolves around IIS web server, the post is still relevant to SSL/TLS handshake in general. Here are few for your reference:
SSL Handshake and IIS
Client certificate Authentication in SSL Handshake
Do not treat CERTIFICATES & SSL as one topic. Treat them as 2 different topics and then try to see who they work in conjunction. This will help you answer the question.
Establishing trust between communicating parties via Certificate Store
SSL/TLS communication works solely on the basis of trust. Every computer (client/server) on the internet has a list of Root CA's and Intermediate CA's that it maintains. These are periodically updated. During SSL handshake this is used as a reference to establish trust. For exampe, during SSL handshake, when the client provides a certificate to the server. The server will try to cehck whether the CA who issued the cert is present in its list of CA's . When it cannot do this, it declares that it was unable to do the certificate chain verification. (This is a part of the answer. It also looks at AIA for this.) The client also does a similar verification for the server certificate which it receives in Server Hello.
On Windows, you can see the certificate stores for client & Server via PowerShell. Execute the below from a PowerShell console.
PS Cert:> ls Location : CurrentUser StoreNames : {TrustedPublisher, ClientAuthIssuer, Root, UserDS...}
Location : LocalMachine StoreNames : {TrustedPublisher,
ClientAuthIssuer, Remote Desktop, Root...}
Browsers like Firefox and Opera don't rely on underlying OS for certificate management. They maintain their own separate certificate stores.
The SSL handshake uses both Symmetric & Public Key Cryptography. Server Authentication happens by default. Client Authentication is optional and depends if the Server endpoint is configured to authenticate the client or not. Refer my blog post as I have explained this in detail.
Finally for this question
How does the HTTPS protocol recognize the certificate? Why can't HTTP work with certificates when it is the certificates which do all the trust/encryption/authentication work?
Certificates is simply a file whose format is defined by X.509 standard. It is a electronic document which proves the identity of a communicating party.
HTTPS = HTTP + SSL is a protocol which defines the guidelines as to how 2 parties should communicate with each other.
MORE INFORMATION
In order to understand certificates you will have to understand what certificates are and also read about Certificate Management. These is important.
Once this is understood, then proceed with TLS/SSL handshake. You may refer the RFC's for this. But they are skeleton which define the guidelines. There are several blogposts including mine which explain this in detail.
If the above activity is done, then you will have a fair understanding of Certificates and SSL.