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
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.
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.
A CA undergoes the requisite vetting to be
trusted and have its issuing roots included in the various root programs.
The CA uses its root certificates to issue and
sign intermediate root certificates.
The CA uses those intermediates to issue
end-user/leaf (server) SSL certificates.
Here’s an SSL certificate chain example from RapidSSLonline.com:
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.
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.
Loading...
