{"id":7198,"date":"2019-06-26T14:53:37","date_gmt":"2019-06-26T18:53:37","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=7198"},"modified":"2023-05-25T11:42:42","modified_gmt":"2023-05-25T15:42:42","slug":"root-certificates-intermediate","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/root-certificates-intermediate\/","title":{"rendered":"The Difference Between Root Certificates and Intermediate Certificates"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\" id=\"h-that-end-user-ssl-certificate-is-only-one-part-of-a-certificate-chain\">That end user SSL certificate is only one part of a certificate chain.<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let\u2019s talk about intermediate and root CA certificates for a few minutes. SSL (or more accurately, TLS) is a technology that most end users know little to nothing about. Even the people acquiring it typically don\u2019t know much beyond the fact they need an SSL certificate, and they have to install it on their server to serve their website via HTTPS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That\u2019s why when you start mentioning Intermediate certificates and CAs and Root certificates and CAs most people\u2019s eyes start to glaze over, which makes it a topic you should probably stay away from on a first date (certificate chains are more of a fourth or fifth date conversation).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But given that SSL is kind of our thing, and because we get asked a lot of questions about them, today we\u2019re going to delve into certificate chains, intermediates and roots. It may seem like a lot at first, but hopefully by the end of this article it will seem pretty straightforward.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So without further ado, let\u2019s hash it out.<span id=\"newline\"><\/span><\/p>\n\n\n<span style=\"--tl-form-height-m:150.25px;--tl-form-height-t:121.4583px;--tl-form-height-d:121.4583px;\" class=\"tl-placeholder-f-type-shortcode_12753 tl-preload-form\"><span><\/span><\/span>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-what-is-a-root-program\">What is a Root Program?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The root certificate, often called a trusted root, is at the center of the trust model that undergirds Public Key Infrastructure, and by extension SSL\/TLS. Let&#8217;s start by discussing root programs and work our way out from there. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Every device includes something called a root store. A root store is a collection of pre-downloaded root certificates (and their public keys) that live on the device itself. Generally, the device will use whatever root store is native to its OS, otherwise it might use a third-party root store via an app like a web browser. There are several major root programs of note:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microsoft<\/li>\n\n\n\n<li>Apple<\/li>\n\n\n\n<li>Google<\/li>\n\n\n\n<li>Mozilla<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Apple users, both macOS and iOS, rely on the Apple root store, likewise for Microsoft users and its root store. Android uses Google&#8217;s. And the Mozilla suite of products uses its own proprietary root store. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The root programs run under extremely strict guidelines. In addition to the regulations and restrictions put forth by the CA\/B Forum&#8217;s Baseline Requirements, some root programs &#8211; for instance, Mozilla&#8217;s &#8211; add even more stringent requirements on top. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The reason for this is simple: trust. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A root certificate is invaluable, because any certificate signed with its private key will be automatically trusted by the browsers. Ergo, you really need to make sure you can trust the <a href=\"https:\/\/www.thesslstore.com\/blog\/what-is-a-certificate-authority-ca-and-what-do-they-do\/\">Certificate Authority<\/a> issuing from it.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In this sense it might be helpful to view trust in two specific contexts:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Social Trust<\/li>\n\n\n\n<li>Technical Trust<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The latter is entirely contingent upon the former. The strict requirements that CAs must adhere to, the audits, the public scrutiny &#8211; it&#8217;s all meant to ensure that the CAs maintain enough social trust to merit the technical trust that comes with having a trusted root. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Generally, these things are pretty straightforward, usually a CA has already been issuing off a cross-signed intermediate (we&#8217;ll get to that in a second) and conducting its own CA business for a period before applying to have its root trusted. Or, put another way, you can&#8217;t just form a CA and immediately apply to have your root trusted. And the deliberations can at times skew political, as we saw with the debate of the DarkMatter CA a few months ago.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Regardless, once a CA has had its application accepted and proved itself trustworthy, it gets its roots added to the root store. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">What is a trusted root certificate?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">As we just covered, a root certificate is a special kind of X.509 digital certificate that can be used to issue other certificates. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For starters, whereas end user or leaf SSL certificates (and generally any kind of publicly trusted PKI certificate) have a lifespan of two years &#8211; tops &#8211; root certificates live much, much longer. Here&#8217;s one of DigiCert&#8217;s EV roots, take a look at the its validity period:<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter\"><img loading=\"lazy\" decoding=\"async\" width=\"405\" height=\"515\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/DigiCert-Root.png\" alt=\"\" class=\"wp-image-11076\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/DigiCert-Root.png 405w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/DigiCert-Root-75x94.png 75w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/DigiCert-Root-236x300.png 236w\" sizes=\"auto, (max-width: 405px) 100vw, 405px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"wp-block-paragraph\">Now, as you&#8217;ve likely inferred by now, each CA has more than one root. In fact, most CAs have several. Here&#8217;s a quick look at the root store on my computer:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"1007\" height=\"980\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Root-Store.png\" alt=\"\" class=\"wp-image-11077\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Root-Store.png 1007w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Root-Store-300x292.png 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Root-Store-768x747.png 768w\" sizes=\"auto, (max-width: 1007px) 100vw, 1007px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Generally different roots will have different attributes. This is probably best illustrated by the two COMODO (now Sectigo) roots near the top of that list. One for making RSA signatures and the other for ECDSA ones. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Any certificate that is issued off any of these roots will automatically be trusted by my computer system. Now, so far we&#8217;re looked at this in an overly simplistic way. The value of these roots, and the risks that come with having one compromised, mean that they&#8217;re rarely actually ever used to issue certificates. Instead the spin up and issue off of intermediates, but before first&#8230;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-what-is-the-certificate-chain\">What is the certificate chain?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before we can&nbsp; go any further, we need to introduce the concept of the certificate chain. Let me start by posing a question: how does your browser know to trust a website\u2019s SSL certificate? We&#8217;ve covered that any certificate descendant of a trusted root is, by extension, trusted. But how does that work on a technical level? <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When you arrive at a website, your browser takes a look at its SSL certificate and performs a quick process to verify the certificate\u2019s authenticity. It checks its validity dates, ensures the certificate hasn&#8217;t been revoked and it authenticates the certificate&#8217;s digital signature.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"alignright\"><img loading=\"lazy\" decoding=\"async\" width=\"300\" height=\"283\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/CSR-Icon-300x283.jpg\" alt=\"difference between root and intermediate certificate\" class=\"wp-image-7200\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/CSR-Icon-300x283.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/CSR-Icon.jpg 407w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"wp-block-paragraph\">What your browser is doing to authenticate the certificate is following the certificate chain.  To get an SSL certificate issued you start by generating a Certificate Signing Request (CSR) and a Private Key. In its simplest iteration, you send the CSR to the certificate authority, it then signs your SSL certificate with the private key from its root and sends it back.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Now, when a browser sees the SSL certificate, it sees that the certificate was issued by one of the trusted roots in its root store (or more accurately, signed with the root\u2019s private key). Since it trusts the root, it trusts any certificate the root signs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Again, this is oversimplified to make it easier to understand. In this example, the server certificate chains directly to the root. Now let&#8217;s mix in intermediates.<\/p>\n\n\n\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe loading=\"lazy\" title=\"Certificates and Certificate Authority Explained\" width=\"960\" height=\"540\" src=\"https:\/\/www.youtube.com\/embed\/x_I6Qc35PuQ?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen><\/iframe>\n<\/div><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-what-is-an-intermediate-certificate\">What is an intermediate certificate?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">As stated above, Certificate Authorities do not issue server\/leaf certificates (end user SSL certificates) directly off of their roots. Those roots are too valuable and there&#8217;s just too much risk.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So, to insulate themselves, CAs generally issue what is called an intermediate root. The CA signs the intermediate root with its private key, which makes it trusted. Then the CA uses the intermediate certificate\u2019s private key to sign and issue end user SSL certificates. This process can play out several times, where an intermediate root signs another intermediate and then a CA uses that to sign certificate. These links, from root to intermediate to leaf &#8211; are the certificate chain.<\/p>\n\n\n<span style=\"--tl-form-height-m:861.156px;--tl-form-height-t:899.625px;--tl-form-height-d:899.625px;\" class=\"tl-placeholder-f-type-shortcode_12653 tl-preload-form\"><span><\/span><\/span>\n\n\n\n<p class=\"wp-block-paragraph\">Here\u2019s a visualization of a certificate chain. For our example we\u2019re only going to use one intermediate to keep it simple. Real-world certificate chains are often far more complicated.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter\"><img loading=\"lazy\" decoding=\"async\" width=\"531\" height=\"414\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Certificate-Chain.jpg\" alt=\"difference between root and intermediate certificate\" class=\"wp-image-7201\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Certificate-Chain.jpg 531w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Certificate-Chain-300x234.jpg 300w\" sizes=\"auto, (max-width: 531px) 100vw, 531px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"wp-block-paragraph\">You may have noticed that sometimes when your CA issues an SSL certificate that it will also send an intermediate certificate that you&#8217;ll need to install, too. That&#8217;s so that browsers will be able to complete the certificate chain and link the SSL certificate on your server back to one of its roots. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Browsers and operating systems vary on how they treat an incomplete chain. Some will just issue and error when an intermediate is missing, others will save and cache intermediates in case they may come in handy later.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter\"><img loading=\"lazy\" decoding=\"async\" width=\"1007\" height=\"464\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/06\/Intermediate-Root-Store.png\" alt=\"\" class=\"wp-image-11080\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/06\/Intermediate-Root-Store.png 1007w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/06\/Intermediate-Root-Store-300x138.png 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/06\/Intermediate-Root-Store-768x354.png 768w\" sizes=\"auto, (max-width: 1007px) 100vw, 1007px\" \/><\/figure>\n<\/div>\n\n\n<h2 class=\"wp-block-heading\" id=\"h-what-role-does-the-digital-signature-play\">What role does the digital signature play?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A digital signature is kind of like a digital form of notarization in this context. When a root certificate digitally signs an intermediate certificate it is essentially transferring some of its trust to the intermediate. Because the signature comes directly from the trusted root certificate\u2019s private key, it\u2019s automatically trusted.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This paragraph will get a little technical, so feel free to skip ahead. Anytime a browser or device is presented with an SSL certificate it receives the certificate itself as well as the public key associated with the certificate. Using the public key, it verifies the digital signature and sees who it was made by \u2013 what certificate signed it. You can probably start piecing this together now. When your browser is authenticating the end user SSL certificate on a website, it uses the public key that is provided to verify the signature and move one link up the chain. It continues repeating this process \u2013 authenticating the signature and following the chain to the certificate that signed it \u2013 until eventually it arrives at one of the root certificates in the browser\u2019s trust store.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If it can\u2019t chain the certificate back to one of its trusted roots, it won\u2019t trust that certificate.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-ok-so-what-is-the-difference-between-a-root-ca-and-an-intermediate-ca\">Ok, so what is the difference between a Root CA and an Intermediate CA?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is actually fairly straightforward. A Root CA is a Certificate Authority that owns one or more trusted roots. That means that they have roots in the trust stores of the major browsers. Intermediate CAs or Sub CAs are Certificate Authorities that issue off an intermediate root. They do not have roots in the browser\u2019s trust stores, instead their intermediate roots chain back to a trusted third-party root. This is sometimes called cross-signing.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"alignleft\"><img loading=\"lazy\" decoding=\"async\" width=\"300\" height=\"271\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/SSL-icon-300x271.jpg\" alt=\"difference between root and intermediate certificate\" class=\"wp-image-7199\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/SSL-icon-300x271.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/SSL-icon.jpg 371w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"wp-block-paragraph\">Now, here\u2019s where it can get a little confusing. As we discussed earlier, CAs do not issue directly from their roots. They add layers of security by issuing intermediates and then signing certificates with those. This helps to minimize and compartmentalize damage in the event of a mis-issuance or security event. Rather than revoke the root certificate and literally every certificate that it signed by extension, you just revoke the intermediate, which only causes the group of certificates issued off that intermediate to get distrusted.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Here\u2019s a practical example, Google and the other browsers <a href=\"https:\/\/www.thesslstore.com\/blog\/final-distrust-symantec-ssl-certificates\/\" target=\"_blank\" rel=\"noopener noreferrer\">recently distrusted Symantec CA brand SSL certificates<\/a>. At first blush that might seem like a monumental task, distrusting millions of end-user SSL certificates. In reality, it was very simple. They just removed all of Symantec CA\u2019s roots from their trust stores. Now any certificate that is supposed to chain back to those roots fails and is distrusted. (It\u2019s worth noting that DigiCert has cleaned up Symantec nicely, but this serves as a good real life example for this discussion.)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-what-s-the-difference-between-a-chained-root-and-a-single-root\">What\u2019s the difference between a chained root and a single root?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">That actually hearkens back to our last question. A single root is possessed by a CA. It can issue certificate directly, making it much simpler to deploy certificates and simplifying installation. A chained root is what a Sub CA uses to issue certificates. It\u2019s an intermediate certificate, but, because the Sub CA doesn\u2019t have its own trusted root is has to chain to a third-party CA that does have one.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This makes a difference, too. Here\u2019s why:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Chained roots make for more complicated installations because the intermediate root will need to be loaded on to every server and application that hosts the certificate.<\/li>\n\n\n\n<li>Chained roots are at the mercy of the CA they are chained to. They have no control over the root, so if the Root CA goes out of business they\u2019re screwed.<\/li>\n\n\n\n<li>Roots and <a href=\"https:\/\/www.thesslstore.com\/blog\/intermediate-certificate-fingerprinting\/\">Intermediate certificates<\/a> expire, too. Albeit on longer timelines. Still, an intermediate must expire before its root, which adds complexity.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"h-a-final-word-on-roots-and-intermediates\">A final word on Roots and Intermediates<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">What we\u2019ve just described \u2013 the trust model involving Certificate Authorities, certificate chains and cryptographic signatures \u2013 is essentially PKI or Public Key Infrastructure. I\u2019ve avoided using that term too much until now because it seems very abstract until you drill down into the specifics a little bit.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But, when someone refers to PKI this is what they mean. And with that in mind, you can probably work out how a Private CA and self-signed certificates are deployed in an Enterprise context. Working alongside a trusted CA, an organization generates a root certificate(s) and private key (this is called a key ceremony). The organization then adds the root to its own root stores, across all its systems and devices. And from that point, the organization can self-sign its own X.509 certificates using the private key from its own roots and they will be trusted across its network.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>As always, leave any comments or questions below&#8230;<\/em><\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"267\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568-1024x267.jpg\" alt=\"Hashed Out by The SSL Store is the voice of record in the SSL\/TLS industry.\" class=\"wp-image-7276\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568-1024x267.jpg 1024w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568-300x78.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568-768x200.jpg 768w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568.jpg 1559w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n<span style=\"--tl-form-height-m:801.312px;--tl-form-height-t:638.344px;--tl-form-height-d:638.344px;\" class=\"tl-placeholder-f-type-shortcode_12763 tl-preload-form\"><span><\/span><\/span>","protected":false},"excerpt":{"rendered":"<p>That end user SSL certificate is only one part of a certificate chain. Let\u2019s talk about intermediate and root CA certificates for a few minutes. SSL (or more accurately, TLS)&#8230;<\/p>\n","protected":false},"author":6,"featured_media":11078,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[130],"tags":[732,196,221],"class_list":["post-7198","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-everything-encryption","tag-certificate-chain","tag-intermediate-certificates","tag-root-certificates","post-with-tags"],"views":482747,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/Roots-feature.png","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/7198","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=7198"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/7198\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/11078"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=7198"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=7198"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=7198"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}