We may earn a commission when you make a purchase via links on this site.

What is a Digital Certificate? 4 Types You Need to Know

By Tibor Moes / September 2022

What is a Digital Certificate? Types You Need to Know

What is a Digital Certificate?

With web security being of major concern to everyone from individual users to organizations, the topic of digital certificates pops up more than ever. You hear of digital certificates of all kinds used online, on internal networks, and you probably used them yourself without question.

You know they have something to do with securing communications or restricting access, but don’t know if they’re worth it. After all, if you tried to get one for your company, you’ll know that they aren’t cheap, despite the many pricing options. So, what is a digital certificate?

Summary: A digital certificate, identity certificate, or public key certificate is an electronic document or password that helps you prove the authenticity of a username, device, or server. It’s used primarily to differentiate restricted from trusted devices and only allows access to a network or browser to authorized individuals.

Tip: Digital certificates are only a small part of the cybersecurity toolkit. Protect your own data with top-tier antivirus software and guard your privacy with a leading VPN provider.

Digital Certificate Examples of Different Types

Digital certificates come in many forms and have various uses. Here are the types you need to know about.

TSL/SSL Digital Certificates

Whenever you see an HTTPS designation on a web address or URL, that server has a TLS/SSL certificate.

This type of digital certificate is mainly used to encrypt and protect communications, hence its use in email applications.

The way it functions is simple. The certificate allows or prevents servers from exchanging messages with clients, depending on how the validation process goes.

The TLS/SSL certificate can be a server or client-side certificate.

Server TLS/SSL Certificate

This type of server certificate uses both TLS and SSL protocols to secure communications between client devices and servers.

It does so by prompting the server to show a digital certificate that indicates it is the desired recipient.

In this scenario, the client device connecting to the server performs a certification path validation process. The process matches the host to the subject on the certificate and shows that a trusted certificate authority was responsible for issuing the certificate.

Interestingly, the host must always be identified as “Common Name.” Since these certificates could be valid for a slew of host names, domains, and subdomains, they should contain a separate field for alternative subject names.

TLS/SSL Client Certificates

A client-side certificate is a type of ID that helps users and devices identify themselves to one another.

Such certificates are helpful in database protection applications. Another use is in email services where client certificates authenticate emails for the recipient.

These aren’t as common in web browsers but are popular in virtual private networks (VPN) and remote desktop service applications to authenticate trusted devices.

A big difference between this and a server certificate is who handles the authentication. In this case, the provider or certificate issuer performs the authentication when the client requests access.

Furthermore, a client certificate can often display a personal name or even an email address identifier instead of a hostname, as is the case with server certificates.

Code Signing Digital Certificates

This certificate is used by software developers and publishers. They use code signing certificates to sign their software and prove it’s genuine.

Users who download them can verify their authenticity before installing to ensure they haven’t been scammed or are about to install something potentially infected with malware.

A TLS/SSL certificate also has subtypes based on its validation methodology.

Organization

An organization validated certificate is most common in the eCommerce industry.

Extended

Large organizations and enterprises that need to protect sensitive information use an extended validation certificate.

This type of TSL/SSL certificate provides complete business authentication and is often associated with the highest level of security.

Domain

The domain validated certificate is the fastest method and the preferred choice for most websites, especially due to how cheap it is to get one.

Where Do You Get Digital Certificates?

If you need a digital certificate, you have to get one from a trusted source. That often means a certificate authority.

A certificate authority, certification authority, or CA for short, is responsible for storing, signing, and issuing digital certificates.

These are trusted and licensed entities by certificate owners and any party that needs a certificate to validate an authentication request.

Having a digital certificate isn’t enough for someone to verify and authenticate its digital signature. To do that, it needs a recognized public key from the issuer, which is the certificate authority.

Fortunately, there are many widely recognized CAs. The advantage of working with one is that their public keys are pre-installed in popular browsers like Firefox, Safari, Chrome, Edge, etc.

Therefore, you can easily use your signed certificates online.

Alternatively, you can create a digital certificate with different issues, for example, using the JSCAPE MFT Server service. Sadly, this will give you a self-signed certificate that may not be automatically recognized or validated.

Here’s why.

Understanding Signed and Self-Signed Digital Certificates

Recognized certificate authorities are trusted issuers. They do their due diligence prior to signing a certificate requested through a certificate signing request, or CSR.

Issuing entities verify the validity of the information included in a digital certificate to ensure that the party that uses them is trustworthy.

Hence, signed certificates are deemed reliable and preferred in the online space.

This is actually the industry norm. Users trying to connect to websites with self-signed certificates will be displayed a browser warning.

The warning is different depending on the browser but generally informs the user that the address they’re trying to reach is untrusted or the connection might not be secure.

While the user can proceed to connect anyway, simply getting that warning could be a turn-off for some people and even make them believe the site is fake.

That’s not to say that self-signed certificates aren’t good. In most cases, these are used internally by large companies and organizations.

Why?

If you run your own network, you can control the access to your servers. Therefore, you can easily use a self-signed certificate behind your firewall to beef up security on file transfers.

What Information Does a Digital Certificate Contain?

Each digital certificate can be very different. However, most certificates share some common fields with specific information.

Serial Number

A serial number is a unique identifier for a certificate in a certificate authority’s system. It’s a necessary piece of information to check against revocation data.

Subject

The subject line usually indicates who or what owns the certificate. It can be an individual, organization, or a specific device.

As previously mentioned, there can be an exception here regarding shared certificates. If this field contains the “Common Name” identifier, you can expect to see another field, “Subject Alternative Name,” that will contain a subject’s actual name.

This is to ensure the certificate can remain valid for multiple hosts.

Issuer

This line indicates the entity responsible for signing and verifying the information in a digital certificate.

Not Before

Every certificate should have clear authenticity timeframes. The “Not Before” line will indicate when the date on which the certificate can be considered valid.

Sometimes this day can be marked in advance of issuing the certificate.

Not After

The “Not After” field contains the date and time when the certificate expires.

Key Usage

Every certificate needs this field because it clearly defines accepted cryptographic uses of the public key.

Extended Key Usage (If Necessary)

A certificate can be used in multiple applications. When that’s the case, an extended key usage field will appear to indicate other uses such as TLS server authentication, code signing, etc.

Public Key

This is the field where the public key owned by the certificate subject is listed.

Signature Algorithm

The signature algorithm field will indicate both the encryption and hashing algorithms.

But they might not be easy to distinguish for the uninitiated. For example, if you were to see a signature algorithm displayed as “sha256RSA” and nothing else, you would be looking at two different algorithms put together.

Sha256 is a known hashing algorithm, while RSA is a dedicated encryption algorithm.

Signature

This is one of the most important fields and essentially the certificate’s body. It contains the signature, which is first hashed and then encrypted using the algorithms listed in the “Signature Algorithm” field.

Digital Certificates in Website Security

Website security arguably makes most use of digital certificates, a fact made evident by the number of HTTPS websites.

Web browsers typically validate the authenticity of HTTPS servers by checking a digital certificate. Once the certificate is authenticated, users feel safer and are more likely to interact with that website.

Here’s how the process works.

A website operator applies for a certificate with a CSR to a certificate authority. The CA reviews the request by looking at the fields in the electronic document to check it against the company’s information.

Then, the CA signs the request and creates a public certificate.

With that certificate, the web server operator can prove to any browser that the provider, or CA, actually issued the certificate to the right owner. Of course, this is only possible when the owner shares the public certificate to multiple browsers.

But that doesn’t mean that digital certificates don’t have weaknesses.

For example, browsers may give no warning to users when a website displays a different certificate. This can happen even when the new certificate has fewer key parts, another provider, or an extended expiry date.

Every web browser should have an approved list of root certificates. But not all root certificates are under the control of entities familiar to users.

Therefore, an organization could issue whatever certificate it wants for a website, and web browsers will find them genuine if they include the issuing entity’s root certificate.

This can sometimes leave you at the mercy of the browser developers.

You can only feel truly secure if you trust the browser’s developers and security protocols to adequately vet root certificates and maintain a list of trusted providers.

Additionally, you have to trust that the certificate providers will behave correctly and keep browser developers informed of untrustworthy and sketchy certificates.

Even though this weakness isn’t often exploited, some fraudulent certificates do get issued occasionally.

Notable CA Exploits

Popular certificate authority VeriSign was the subject of CA subversion in 2001. The CA issued not one but two different certificates to a third party claiming to represent IT giant Microsoft.

Both certificates had the name “Microsoft Corporation.”

Why was this a big deal?

Having those certificates would’ve allowed the owner to spoof Microsoft domains, emails, and applications to potentially steal confidential information, install malware, and perform all sorts of other nefarious acts.

Fortunately, both Microsoft and VeriSign caught on quickly and resolved the issue.

Another fraudulent certificate was issued in 2008 for the name “mozilla.com” to a person who had no right to represent Mozilla. In this case, Certstar was the issuing CA.

In 2011, both Comodo and DigiNotar issued fraudulent certificates to alleged Iranian hackers. Those certificates were purportedly used to initiate a man-in-the-middle attack.

This type of cyber attack allows someone to position themselves between two or more communicating parties and intercept data, files, and communications. In some cases, the man in the middle could even alter the message, which can have massive implications when used for financial or political gain.

In some instances, it took a lot of time for web browsers to figure it out and update their root certificate lists by removing the fraudulent certificates.

Still, proof of a TLS/SSL digital certificate should make users feel better about a website’s authenticity.

In fact, TLS certification is a point of emphasis in most security guidelines, especially for websites that have access to confidential information or conduct financial transactions. Whether it’s a banking website, investment platform, eCommerce marketplace, etc.

Such platforms should always be protected by public key certificates. Knowing that, you might want to reevaluate your browsing habits and trusted websites.

Issues With Key Storage

Another weakness of a digital certificate is the potential theft of the private keys belonging to CAs.

Should this occur, the thief could use those keys to create fake certificates on demand. But because they have the private keys, the certificates would look genuine once signed.

There’s no way to protect against this unless the theft is immediately discovered. Even then, such a theft could compromise multiple certificates, servers, and users.

Luckily, most CAs use multiple security measures to prevent this from happening.

Using hardware security modules to store private keys is a great way to prevent theft because the modules are kept offline.

Additionally, a wide range of software controls can be implemented to restrict access and prevent theft.

CAs that go one step further even use specific protocols or ceremonies when generating a new signing key to prevent tampering.

Few, if any, CA private key tampering or theft cases are known to the general public.

Most exploits came from compromising or fooling CAs to issue fraudulent certificates.

Root Programs Examples

Some of the world’s leading certificate authorities use the following root programs:

  • Mozilla Root Program

  • Microsoft Root Program

  • Apple Root Program

  • Java Root Program

Why is it important to know about these root programs?

As explained above, web browsers will trust a wide range of certificates issued by CAs based on the root programs they use for authentication.

Here’s an example of how this works.

Chrome trusts CAs listed in the Microsoft Root Program when used from a Windows device. But because Chrome uses the operating system to select its trusted CAs, it will use the Apple Root Program when installed on an iOS or macOS system.

This is different than the approach used by Firefox. Firefox relies on its own operating system trusted list, and therefore uses the Mozilla Root Program to assign trust levels to various CAs.

It does this regardless of what platform or operating system it has installed, like Windows, macOS, Linux, etc.

Edge and Safari use a similar approach and only rely on their OS trust stores.

What’s interesting about root programs is how they can be shared.

Take the Mozilla Root Program, for instance. Since Firefox is an open-source browser, its certificate list can also be copied.

Therefore, other operating systems, like those based on Linux, can use the Mozilla Root Program to create their own list of trust authorities for its built-in browser and applications.

Each root program should contain a list of reasons for which a certificate issuer can be trusted. But that doesn’t mean all CAs are trusted for all types of certificates.

One that is known for its TLS server certificates may not be on the trust list for code signing certificates and vice versa.

Get Your Certificate From a Trusted Source

While CAs aren’t exactly regulated all over the world, you can usually spot the most trusted issuers by looking at what root programs the biggest websites and corporations trust.

Only by working with a trusted issuer can you ensure you’re getting a good deal, security, and inclusion in root program lists on various browsers. Making the wrong choice could make it harder for your customers and clients to interact with you from different platforms.

You might also go with a reputable CA even when you need a self-signed certificate for internal use and use an IT specialist to implement this complex authentication protocol on your network.

Resources

 

Frequently Asked Questions

Is a Digital Certificate the same as a Digital Signature?

Not exactly. A digital signature is used to ensure the security of information once issued. However, a digital certificate also binds the signature to an issuing, trusted entity.

Is HTTPS a Digital Certificate?

The term HTTPS, which stands for Hyper Text Transfer Protocol Secure, is not a digital certificate. Instead, it indicates that a website is secured by an SSL digital certificate issued by a trusted authority.

What are the three elements included in a Digital Certificate?

Three of the most important bits of information will have identifying information about the owner, a digital signature, and the public key validated by the certificate.

Author: Tibor Moes

Author: Tibor Moes

Founder & Chief Editor at SoftwareLab

Tibor is a Dutch engineer and entrepreneur. He has tested security software since 2014.

Over the years, he has tested most leading antivirus software for Windows, Mac, Android, and iOS, as well as many VPN providers.

He uses Norton to protect his devices, CyberGhost for his privacy, and Dashlane for his passwords.

This website is hosted on a Digital Ocean server via Cloudways and is built with DIVI on WordPress.

You can find him on LinkedIn or contact him here.

Don't take chances online. Protect yourself today:

Best Antivirus Icon - SoftwareLab

Compare Antivirus

Protect your Devices

Best VPN Icon - SoftwareLab

Compare VPN

Protect your Privacy

Or directly visit the #1:

[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]
[class^="wpforms-"]