A public key certificate is a digitally signed document that validates the sender’s identity and authorization. It employs a cryptographic framework that associates a public key with a specific entity, such as a user or organization. A trustworthy third party known as a certification authority creates and issues the digital document.
Public key certificates, also known as digital certificates, contain the public key, the owner’s identifying information, and the name of the issuing certificate authority (CA). A trusted third party, the CA, generates digital certificates that validate the identity of parties in an information exchange over the internet. A digital certificate provides assurance of a person’s identity, and the CA establishes that assurance by validating the identity of the person who requests the certificate.
Public key certificates form a part of a public key infrastructure (PKI) system that uses encryption technology to secure messages and data. A public key certificate uses a pair of encryption keys, one public and one private. The public key is made available to anyone who wants to verify the identity of the certificate holder, while the private key is a unique key that is kept secret.
This enables the certificate holder to digitally sign documents, emails and other information without a third party being able to impersonate them. The four main components of PKI are public key encryption, trusted third parties such as the CA, the registration authority and the certificate database or store.
There are different types of public key certificates for different functions, such as authorization for a specific type of action. The following are common fields found in digital certificates:
- Serial number. This number distinguishes the certificate from other certificates.
- Algorithm information. The issuer uses this algorithm to sign the certificate.
- Issuer. This is the name of the CA that issued the certificate.
- Validity period of the certificate. These are the start and end dates that define when the certificate is valid.
- Subject distinguished name. This is the name of the identity to which the certificate is issued.
- Subject public key information. This is the public key that is associated with the identity.
What Are The Different Types of Certificates?
Transport Layer Security/Secure Sockets Layer (TLS/SSL) certificates. These certificates are the core of the transport layer security (TLS) protocol, which is an updated version of SSL. These digital files contain a public encryption key that is used to validate server identity and a digital signature to ensure the integrity and the source of data and other information transmitted online. These certificates facilitate the exchange of encryption keys between web servers and browsers, which enable a secured connection.
The chain of trust, trust path or trust chain is a sequence of certificates that a web browser must traverse to verify that a particular website is authentic and, therefore, secure. A chain of trust typically includes a root certificate, an intermediate certificate and a leaf certificate.
There are multiple types of TLS/SSL certificates:
- Domain validation (DV) certificates. These certificates are typically the most basic and most affordable type of certificate web browsers trust. DV certificates require that the domain name of an organization is verified by the issuing CA before they are issued. These certificates can be issued within minutes and do not require the website owner to prove their identity. When a browser sees a DV certificate, it trusts that the owner of the domain is indeed the owner of the certificate and that the certificate is only meant for that specific domain.
- Organization validation (OV) certificates. An OV certificate is one of the ways that organizations can be validated for quality assurance through a formal and accredited process. Organization validation is a process of validating the identity of the root certificate authority, followed by a validation of the business or organization requesting the certificate.
- Individual validation (IV) certificates. These are certificates that are issued to individuals — not organizations — making them popular choices among consumers, particularly for securing email.
- Extended validation (EV) certificates. These certificates are issued after an extensive vetting process by both a CA and the CA’s reputation partners. Under the EV guidelines established by the CA/Browser Forum, in addition to meeting the validity requirements, the applicant must submit proof of their identity, and the organization must pass an independent audit. The combination of these factors helps to provide an extra layer of trust in the identity of the site owner. Companies issuing EV certificates are also required to pass an independent audit.
While less common than server certificates, client certificates authenticate the identity of the user who wants to connect to a TLS service, rather than a device seeking a connection.
Email certificate. Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for sending encrypted email. RSA Security created it to resolve the problem of sending encrypted emails without the need to exchange a public key. It is commonly used within an organization that has its own CA.
EMV certificate. EMV payment cards have an embedded microchip containing a card issuer certificate. The embedded microchip enables the EMV payment card to generate a unique code for each transaction. EMV stands for Europay, MasterCard and Visa, the organizations that constitute the certificate authority.
Code-signing certificate. Code-signing certificates are used in software development and IT operations to digitally sign the software or firmware of an application or device. This provides recipients with assurance about who created the code and the integrity of the code.
Root certificate. A root certificate is a digital certificate that is used to sign other digital certificates. It is sometimes referred to as a trust anchor because it is at the top of a hierarchy of digital certificates that are used to verify other digital certificates. The hierarchy starts with a root certificate, which is the highest level of certificate. The root certificate is verified by a second-level certificate, which is verified by a third-level certificate, and so on.
Intermediate certificate. The intermediate certificate is used to sign other certificates and is best used as a bridge between a root CA and a subordinate CA. An intermediate certificate is used to sign end-user certificates that a website or a local server uses. The root certificates verify the identity of the intermediate certificate, which in turn verifies the end-user certificates.
Leaf certificate. A leaf certificate, or an end entity, is the endpoint for the signing and encrypting of data and cannot be used to sign other certificates. These include TLS/SSL, email and code-signing certificates.
Self-signed certificate. A self-signed certificate is a certificate that is signed by the same entity to whom it is assigned. Most certificates can be self-signed and are verified by their own public key. They are not signed by a CA, which means they might be perceived as less trustworthy.
What is a Public Key Example?
Public and private keys form the basis for public key cryptography, also known as asymmetric cryptography. In public key cryptography, every public key matches only one private key. Together, they are used to encrypt and decrypt messages. If you encode a message using a person’s public key, they can only decode it using their matching private key.
Public and private keys: an example
Bob wants to send Alice an encrypted email. To do this, Bob takes Alice’s public key and encrypts his message to her. Then, when Alice receives the message, she takes the private key that is known only to her in order to decrypt the message from Bob.
Although attackers might try to compromise the server and read the message, they will be unable to because they lack the private key to decrypt the message. Only Alice will be able to decrypt the message as she is the only one with the private key. And, when Alice wants to reply, she simply repeats the process, encrypting her message to Bob using Bob’s public key.
Public keys have been described by some as being like a business’ address on the web – it’s public and anyone can look it up and share it widely. In asymmetric encryption, public keys can be shared with everyone in the system. Once the sender has the public key, he uses it to encrypt his message.
Each public key comes paired with a unique private key. Think of a private key as akin to the key to the front door of a business where only you have a copy. This defines one of the main differences between the two types of keys. The private key ensures only you can get through the front door. In the case of encrypted messages, you use this private key to decrypt messages
Together, these keys help to ensure the security of the exchanged data. A message encrypted with the public key cannot be decrypted without using the corresponding private key.
Generating public and private keys
The public and private key are not really keys but rather are really large prime numbers that are mathematically related to one another. Being related in this case means that whatever is encrypted by the public key can only be decrypted by the related private key.
A person cannot guess the private key based on knowing the public key. Because of this, a public key can be freely shared. The private key however belongs to only one person.
There are several well-known mathematical algorithms that are used to produce the public and private key. Some well-respected algorithms include:
- Rivest-Shamir-Adelman (RSA) – Oldest of the public-private key cryptography systems. Frequently used to transmit shared keys for symmetric key cryptography
- Digital Signature Standard (DSS) – a Federal Information Processing Standard specifying the algorithms that can be used to generate digital signatures used by NIST
- Elliptic curve cryptography (ECC)– As its name implies, ECC relies on elliptic curves to generate keys. Often used for key agreements and digital signatures. At PreVeil, we use elliptic-curve cryptography’s Curve-25519 and NIST P-256.
Real world examples
- Digital signatures
Public and private keys can also be used to create a digital signature. A digital signature assures that the person sending the message is who they claim to be.
Typically, we use the recipient’s public key to encrypt the data and the recipient then uses their private key to decrypt the data. However, using the scheme of digital signatures, there’s no way to authenticate the source of the message. Mike could get a hold of Alice’s public key (since it’s public) and pretend that Bob is the person sending a message to Alice.
To create a digital signature, Bob digitally signs his email to Alice using his private key. When Alice receives the message from Bob, she can verify the digital signature on the message came from Bob by using his public key. As the digital signature uses Bob’s private key, Bob is the only person who can create the signature.
PreVeil’s method for securing messages is a bit more complex than the example provided above. However, the example provides a good general overview for how asymmetric encryption works.
- Diffie-Helman key exchange
The Diffie Hellman key exchange demonstrates an example of how users can securely exchange cryptographic keys over a public channel.
In the past, secure encrypted communication required that the individuals first exchange keys by a secure means such as paper key lists transported by a trusted courier. The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel.
PreVeil uses the Diffie Hellman key exchange to enable Web PreVeil. Web PreVeil is a browser based end-to-end encrypted email service that allows users to easily access their secure email account on the web without any software download or any passwords to remember.
Business benefits of public private key encryption
By using a public and private key for encryption and decryption, recipients can be confident that the data is what the sender says it is. The recipient is assured of the confidentiality, integrity and authenticity of the data.
Confidentiality is ensured because the content that is secured with the public key can only be decrypted with the private key. This ensures that only the intended recipient can ever review the contents
Integrity is ensured because part of the decryption process requires checking that the received message matches the sent message. This ensures that the message has not been changed in between.
Authenticity is ensured because each message sent by Alice to Bob is also signed by Alice’s private key. The only way to decrypt Alice’s private key is with her public key, which Bob can access. By signing the message with her private key, Alice ensures the authenticity of the message and shows that it really did come from her.