A certificate contains a public key

What is the difference between a certificate and a key in terms of SSL?

Whenever I try to understand something about SSL, I always find it difficult to keep track of what "key" and "certificate" are referring to. I'm afraid a lot of people use them incorrectly or interchangeably. Is there a standard difference between a key and a certificate?


A certificate contains a public key.

The certificate contains not only the public key, but also additional information such as the issuer, the purpose of the certificate and other types of metadata.

As a rule, a certificate itself is signed by a certification authority (CA) with the CA's private key. This is used to check the authenticity of the certificate.

Let's say Company A has a keypair and needs to publish its public key for public use (also known as ssl on its website).

  • Company A must send a Certificate Request (CR) to a Certificate Authority (CA) to obtain a certificate for its key pair.
  • The public key, but not the private key, of Company A's key pair is part of the certificate request.
  • The CA then uses Company A's identity information to determine whether the request meets the CA's criteria for issuing a certificate.
    If the certification authority approves the request, it issues a certificate to Company A. In short, the certification authority signs Company A's public key with the private key of its certification authority, which verifies its authenticity.

Company A's public key, which is signed with the private key of a valid certification authority, is known as Company A's certificate.

Let me explain with an example.

In the normal key pair-based PKI there is a private key and a public key.

In a certificate-based system there is a private key and a certificate. The certificate contains more information than the public key.

Demo (you can create a certificate and private key): http://www.selfsignedcertificate.com/

You can download the private key file and certificate. You can see that the certificate file contains a lot of information as shown below.

You can match your generated certificate (which will be opened with a text editor) and your private key (which will be opened with a text editor) on this website: https://www.sslshopper.com/certificate-key-matcher.html

If the certificate matches the client's private key, the client is sure that the certificate is provided by the client or the client's Trusted Agent (CA).

However, there are problems only when communicating with private keys and certificates .

Since anyone can generate their own certificate and private key, a simple handshake doesn't prove anything about the server other than that the server knows the private key that matches the certificate's public key. One way to solve this problem is to let the client have a or has more than one certificate that he trusts. If the certificate is not in the set, the server cannot be trusted .

This simple approach has several disadvantages. Servers should be able to upgrade to stronger keys over time ("key rotation"), which replaces the public key in the certificate with a new one. Unfortunately, the client app now needs to be updated as it is essentially a change in the server configuration. This is especially problematic when the server is not under the control of the app developer, e.g. B. if it is a third-party web service. This approach also has problems when the app needs to communicate with any server like a web browser or an email app.

To overcome these drawbacks, servers are typically configured with certificates from well-known issuers called Certificate Authorities (CAs). The host platform (client) generally contains a list of known CAs that it trusts. Similar to a server, a certification authority has a certificate and a private key. When issuing a certificate for a server, the certification authority signs the server certificate with its private key. The client can then check whether the server has a certificate that was issued by a certification authority known to the platform.

However, in solving some problems, using certification authorities leads to another. Because the certification authority issues certificates for many servers, you still need to ensure that you are communicating with the server you want to use. To fix this, the certificate issued by the CA identifies the server with either a specific name like gmail.com or a group of hosts with wildcard characters like * .google.com.

The following example will make these concepts a little more concrete. The following snippet from a command line uses the s_client command of the openssl tool to display the Wikipedia server certificate information. It specifies port 443 as this is the standard for HTTPS. The command sends the output from openssl s_client to openssl x509, which formats information about certificates according to the X.509 standard. Specifically, the command asks for the subject, which contains the server name information, and the issuer, which identifies the certification authority.

You can see that the certificate was issued for servers that match * .wikipedia.org by the RapidSSL certification authority.

As you can see, based on this additional information sent from CA to server, the client can easily tell whether or not it is communicating with its server.

An SSL certificate is obtained from a trusted certification authority that guarantees the secure connection of the website. SSL certificates usually contain the authentication logo and the public keys required to encrypt and decrypt data to be sent to the computer. Key SSL functions

Several SSL- key to be generated. They are used to encrypt and decrypt the information sent to and from the computer. The keys are used to check whether the information has been changed or tampered with.

Life cycle difference

Certificates last longer than SSL keys. SSL certificates are obtained from the certification authority, which banks and companies can renew on a regular basis. SSL keys or session keys, on the other hand, are generated uniquely during the session and discarded after the session has ended.

Read more here

OK, let's break this down so non-tech people can understand.

Think of it this way. A certificate is like a safe in your bank. It contains a lot of important things; generally things that contain your identity. The certificate has a public key and needs a private key to open.

Your locker also opens with two keys, just like a certificate.
In the case of a safe, the bank key is like the public key, since it remains with the bank and the public key remains with the certificate. You have the private key that is needed to "get your certificate", and in the safe example, your private key is also required in addition to the public key.

Before you can actually open your locker, you must first verify your identity (similar to a certificate request). Once identified, use your private key along with your public key to open your security box. This is a bit like making your certificate request and then getting your certificate from the certification authority (provided you can be identified (trusted) and have the correct key).

We use cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from.

By continuing, you consent to our use of cookies and other tracking technologies and affirm you're at least 16 years old or have consent from a parent or guardian.

You can read details in our Cookie policy and Privacy policy.