How to Get an SSL Certificate Chain<\/h2>\n\n\n\n
When you arrive at a website, the serving hosting sends a\ncopy of its SSL certificate to your browser as part of what\u2019s known as a \u201chandshake.\u201d\nThe handshake process is where authentication occurs and the parameters of a\nsecure, encrypted HTTPS connection are negotiated. To authenticate the server,\nyour browser will perform a series of checks on the certificate its presented.\nIt will check certificate transparency (CT) logs, online certificate status\nprotocol (OCSP) servers, revocation lists, and the digital signature on the\ncertificate itself.<\/p>\n\n\n\n
This last part, verifying the digital signature, is where\nthe certificate chain comes in.<\/p>\n\n\n\n
Starting at the Bottom \u2013 With the Roots<\/h2>\n\n\n\n
Certificate\nauthorities<\/a> (CAs) are the organizations responsible for issuing trusted\ndigital certificates. They\u2019re strictly monitored and must comply with stringent\nstandards to ensure they maintain their trusted status. The return for this is\nthat their issuing root certificates get included in the major root stores run\nby the various OSs and browsers. <\/p>\n\n\n\n When a certificate is issued, the CA performs a validation\nof the entity requesting the certificate. Once that\u2019s satisfied, it issues a\ncertificate that includes the validated information and signs it with the\nissuing certificate\u2019s private key.<\/p>\n\n\n\n This digital signature can be verified using the same\ncertificate\u2019s public key.<\/p>\n\n\n\n It all starts with the root certificate. These are\nincredibly powerful, long-lived digital certificates that can be used to issue\nother trusted certificates. This is all done with digital signatures. <\/p>\n\n\n\n But CAs don\u2019t issue directly off their root certificates.\nThat would be too dangerous and also raises a laundry list of technical issues.\nInstead, to protect the root certificates, the CAs spin up and sign intermediate\nroots<\/a>. Whereas the root certificates themselves reside in root stores and\nphysically live on the devices that use those root stores, the intermediate\nroots do not. This is why it\u2019s oftentimes necessary to install an intermediate\nalongside your end user or leaf SSL certificate.<\/p>\n\n\n\n This will all make more sense when we put it together.<\/p>\n\n\n\n Here\u2019s an SSL certificate chain example from RapidSSLonline.com:\n<\/p>\n\n\n\n Now, let\u2019s talk about the actual trust model that leverages\nthe SSL certificate chain. Remember earlier when we talked about how the\nbrowser receives the server\u2019s SSL certificate during the handshake? Well, in\naddition to the leaf certificate, it also receives any associated intermediates.\nThese intermediates are needed to complete the chain. Oftentimes, modern\nbrowsers will cache intermediates in case the server doesn\u2019t have all the right\ncertificates installed, but if you\u2019re a site owner, it\u2019s always best to ensure\nyou have the completed certificate chain at your users\u2019 disposal.<\/p>\n\n\n\n When the user receives the certificate, it checks the\ndigital signature. So, in the case of the leaf certificate, it checks the\nsignature that was left by the intermediate root that issued it. That intermediate\nshould also be installed, and its public key comes included, so the browser\nuses its public key to verify the signature on the leaf certificate. <\/p>\n\n\n\n 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\u2019s 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.<\/p>\n\n\n\n Protect a website in a few minutes with DV SSL or Domain Validated SSL Certificate.<\/p>\n Get a DV SSL certificate, starting at $12.42\/year<\/a><\/p>\n<\/div>\n\n\n\n If you can chain the signatures back to the root, it means\nthat the end user certificate is descendant of that root. That root is trusted,\nso anything it signs is trusted. <\/p>\n\n\n\n Long story short \u2014 as long as a certificate can be chained\nback to one of the roots in a device\u2019s root store, that device will trust it. If\nit can\u2019t be chained back to the root, your browser will issue\na warning<\/a> about the certificate.<\/p>\n\n\n\n Which more than you can say for anybody with a chain wallet.<\/p>\n","protected":false},"excerpt":{"rendered":" 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<\/p>\nHow to Validate the SSL Certificate Chain<\/h3>\n\n\n\n
The SSL Certificate Chain Order<\/h2>\n\n\n\n
![\"Graphic:](\"https:\/\/www.rapidsslonline.com\/ssl\/wp-content\/uploads\/2019\/07\/SSLCertificateChain.png\")
<\/figure>\n\n\n\nFollowing the SSL Certificate Chain<\/h2>\n\n\n\n
Save Up to 80% on DV SSL Certificates<\/h2>\n
Wrapping This Up<\/h2>\n\n\n\n