Tag Archives: SSL certificate chain

What is a GeoTrust RSA CA Certificate?

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)

A breakdown of this intermediate certificate and how it’s used

The GeoTrust RSA CA certificate is an intermediate root in the GeoTrust public key infrastructure (PKI) that is sometimes required to complete a certificate chain during the SSL handshake.

One of the main reasons we use SSL certificates is to identify the entity… err, website that you’re connecting to. The way this is done is called PKI or public key infrastructure. When you first connect to a website, your browser examines its certificate. One of the ways it makes sure the certificate is legitimate is by following what’s called a certificate chain.

GeoTrust RSA CA and Where Intermediates Fall in the Certificate Chain

Graphic of the certificate chain to represent the GeoTrust RSA CA as an intermediate certificate

Certificate authorities (CAs), the organizations that issue certificates, do this on a technical level using what are called “root” certificates. These are a special kind of digital certificate that can issue other digital certificates. These root certificates are part of a “root store” that literally lives on your device. Anytime a certificate is presented, your device needs to be able to link it back to one of those roots.

The problem is that issuing certificates directly off those roots is dangerous, so CAs instead issue intermediate roots and use those to issue certificates to websites. Those intermediate roots are part of the certificate chain, but they don’t reside on anyone’s device. This means you need to install a copy of the intermediate root along with your SSL certificate to complete the chain.

It’s important to note that some browsers and devices do cache intermediate certificates in case one isn’t present when they try to connect to a site. This is why it’s important, as a matter of best practice, to always install any intermediates that are included with your SSL certificate — regardless of whether they come from a GeoTrust RSA CA or another certificate authority.

Save Up to 82% on GeoTrust SSL Certificates

Protect a website (or set of domains) in a few minutes with a DV, OV, or EV validated SSL certificate.

Get a premium DV SSL certificate, starting at $62.58/year

What is the SSL Certificate Chain? Explained by a Certificate Authority

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)

A look at the SSL certificate chain order and the role it plays in the trust model

There are tons of different kinds of chains: gold chains, bike chains, evolutionary chains, chain wallets… Today we’re going to discuss the least interesting of those chains: the SSL certificate chain.

Public key infrastructure (PKI) is a hierarchy of trust that uses digital certificates to authenticate entities. There are myriad uses for PKI — everything from digital signatures to encrypted internet connections. One thing all of them share in common is they use a certificate chain to establish identity.

How to Get an SSL Certificate Chain

When you arrive at a website, the serving hosting sends a copy of its SSL certificate to your browser as part of what’s known as a “handshake.” The handshake process is where authentication occurs and the parameters of a secure, encrypted HTTPS connection are negotiated. To authenticate the server, your browser will perform a series of checks on the certificate its presented. It will check certificate transparency (CT) logs, online certificate status protocol (OCSP) servers, revocation lists, and the digital signature on the certificate itself.

This last part, verifying the digital signature, is where the certificate chain comes in.

Starting at the Bottom – With the Roots

Certificate authorities (CAs) are the organizations responsible for issuing trusted digital certificates. They’re strictly monitored and must comply with stringent standards to ensure they maintain their trusted status. The return for this is that their issuing root certificates get included in the major root stores run by the various OSs and browsers.

How to Validate the SSL Certificate Chain

When a certificate is issued, the CA performs a validation of the entity requesting the certificate. Once that’s satisfied, it issues a certificate that includes the validated information and signs it with the issuing certificate’s private key.

This digital signature can be verified using the same certificate’s public key.

It all starts with the root certificate. These are incredibly powerful, long-lived digital certificates that can be used to issue other trusted certificates. This is all done with digital signatures.

But CAs don’t issue directly off their root certificates. That would be too dangerous and also raises a laundry list of technical issues. Instead, to protect the root certificates, the CAs spin up and sign intermediate roots. Whereas the root certificates themselves reside in root stores and physically live on the devices that use those root stores, the intermediate roots do not. This is why it’s oftentimes necessary to install an intermediate alongside your end user or leaf SSL certificate.

The SSL Certificate Chain Order

This will all make more sense when we put it together.

  1. A CA undergoes the requisite vetting to be trusted and have its issuing roots included in the various root programs.
  2. The CA uses its root certificates to issue and sign intermediate root certificates.
  3. The CA uses those intermediates to issue end-user/leaf (server) SSL certificates.

Here’s an SSL certificate chain example from RapidSSLonline.com:

Graphic: ssl certificate chain example

Following the SSL Certificate Chain

Now, let’s talk about the actual trust model that leverages the SSL certificate chain. Remember earlier when we talked about how the browser receives the server’s SSL certificate during the handshake? Well, in addition to the leaf certificate, it also receives any associated intermediates. These intermediates are needed to complete the chain. Oftentimes, modern browsers will cache intermediates in case the server doesn’t have all the right certificates installed, but if you’re a site owner, it’s always best to ensure you have the completed certificate chain at your users’ disposal.

When the user receives the certificate, it checks the digital signature. So, in the case of the leaf certificate, it checks the signature that was left by the intermediate root that issued it. That intermediate should also be installed, and its public key comes included, so the browser uses its public key to verify the signature on the leaf certificate.

Provided that checks out, it moves to the digital certificate that was affixed to the intermediate by whatever certificate issued it. This could be one of the roots in its trust store, or another intermediate. Regardless, it takes the signing certificate’s public key and verifies the signature on the previous certificate. It continues to do this until it reaches one of the roots in its root store.

Save Up to 80% on DV SSL Certificates

Protect a website in a few minutes with DV SSL or Domain Validated SSL Certificate.

Get a DV SSL certificate, starting at $12.42/year

Wrapping This Up

If you can chain the signatures back to the root, it means that the end user certificate is descendant of that root. That root is trusted, so anything it signs is trusted.

Long story short — as long as a certificate can be chained back to one of the roots in a device’s root store, that device will trust it. If it can’t be chained back to the root, your browser will issue a warning about the certificate.

Which more than you can say for anybody with a chain wallet.