{"id":7425,"date":"2018-09-18T14:59:15","date_gmt":"2018-09-18T18:59:15","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=7425"},"modified":"2023-03-31T12:29:57","modified_gmt":"2023-03-31T16:29:57","slug":"what-is-a-rogue-certificate","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/what-is-a-rogue-certificate\/","title":{"rendered":"What is a Rogue Certificate? How do you prevent them?"},"content":{"rendered":"<h2>A rogue certificate can wreak havoc on your company \u2013 here\u2019s how to prevent that.<\/h2>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-medium wp-image-7435\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Certificate-e1537298304980-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Certificate-e1537298304980-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Certificate-e1537298304980.jpg 400w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>One of the most frequent questions we get asked is, \u201cwhat is a rogue certificate?\u201d And unfortunately, the answer isn\u2019t quite as exciting as the name connotes. Still, rogue certificates represent a major threat to Enterprise businesses. Really, any business \u2013 it\u2019s just that Enterprises have the most surface to cover, which means they\u2019re easier to miss.<\/p>\n<p>To answer the question \u201cwhat is a rogue certificate?\u201d we\u2019re going to have to start with a little bit of background, discuss what it means when a Certificate Authority (CA) goes rogue and we\u2019ll end our discussion with some tips on preventing rogue certificates from affecting your business.<\/p>\n<p>So, what is a rogue a certificate? Let\u2019s hash it out.<span id=\"newline\"><\/span><\/p>\n<h2>What your digital certificate is really authenticating<\/h2>\n<p>Let\u2019s start by talking about the authentication aspect of Public Key Infrastructure \u2013 specifically in an SSL\/TLS context. When a digital certificate is issued, you send the Certificate Authority your public key and a Certificate Signing Request, complete with all relevant information. The CA validates it and returns a signed digital certificate that contains the validated information.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-medium wp-image-7433\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Secure-Site-e1537298339898-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Secure-Site-e1537298339898-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Secure-Site-e1537298339898.jpg 398w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>Now, there are higher levels of validation, which authenticate businesses (Organization Validation and Extended Validation), we\u2019re going to ignore those in this discussion and focus on the one authentication that all SSL\/TLS certificates provide: server authentication.<\/p>\n<p>When the CA performs domain validation it\u2019s attempting to verify that the certificate request came from the domain\u2019s legitimate owner.<\/p>\n<p>There are a few ways to do this, the CA\/Browser Forum (which determines the baseline requirements that government certificate issuance) actually <a href=\"https:\/\/www.thesslstore.com\/blog\/cab-forum-bans-whois-legal-opinions-for-domain-validation\/\">just strengthened the checks that are made<\/a>.<\/p>\n<p>But the idea is always the same, the CA needs to verify that you are indeed the owner of the domain that is living on that server.<\/p>\n<p>Once it\u2019s done this, the CA issues the certificate. This is how it\u2019s supposed to work.<\/p>\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<h2>So, what is a rogue certificate?<\/h2>\n<p>A rogue certificate is a legitimate, trusted certificate that has been issued by a trusted certificate authority but is either <a href=\"https:\/\/www.thesslstore.com\/blog\/heres-what-happens-when-your-private-key-gets-compromised\/\">compromised<\/a> or was issued to the wrong party. There are a few ways this can happen \u2013 we will get to those in a moment.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-medium wp-image-7438\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Security-Shield-e1537298122513-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Security-Shield-e1537298122513-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Security-Shield-e1537298122513.jpg 400w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>We\u2019re not going to go in-depth in discussing the trust model (<a href=\"https:\/\/www.thesslstore.com\/blog\/root-certificates-intermediate\/\">here\u2019s a full description<\/a>), but let\u2019s at least cover the basic concepts. When a CA issues a certificate, it signs that certificate with one of its <a href=\"https:\/\/www.thesslstore.com\/blog\/public-key-cryptography-key-exchange\/\">private keys<\/a>. This private key was either signed by a trusted root, or was signed by an intermediate root that was signed by the trusted root. Either way, when a browser receives a trusted SSL certificate, it follows the digital signature back to the certificate it\u2019s associated with until it eventually reaches one of the trusted roots in its trust store.<\/p>\n<p>As long as the certificate\u2019s signature can be chained back to a root the certificate is trusted. A rogue certificate is a trusted certificate that is associated with a site that the certificate\u2019s owner doesn\u2019t actually control.<\/p>\n<p>Eric Vandenburg, the VP of TCDI (Technology Concepts &amp; Design, Inc.) <a href=\"https:\/\/www.tcdi.com\/the-threat-of-rogue-certificate-authorities\/\">paints a pretty clear picture of why this is dangerous<\/a>:<\/p>\n<blockquote><p>Rogue certificates allow attackers to create illegitimate sites that are indistinguishable from real sites like eBay, Google or PNC because their certificate hierarchy can be validated.\u00a0 Users then will be redirected to such sites through phishing or \u201dman in the middle\u201d attacks where a compromised host in-between the user and a legitimate site sends traffic to an illegitimate site instead.<\/p><\/blockquote>\n<p>We cover on a regular basis <a href=\"https:\/\/www.thesslstore.com\/blog\/unicode-domain-phishing\/\">how convincing phishing websites are<\/a>. <a href=\"https:\/\/www.thesslstore.com\/blog\/1-4-million-new-phishing-websites-created-every-month\/\">How prevalent they are<\/a>. <a href=\"https:\/\/www.thesslstore.com\/blog\/macewan-university-phishing-scam-cautionary-tale\/\">How dangerous they are<\/a>. And up until recently, Google\u2019s HTTPS indicator \u2013 <a href=\"https:\/\/www.thesslstore.com\/blog\/google-will-remove-the-secure-indicator-in-september\/\">which placed a \u201cSecure\u201d badge beside the URL in the address bar<\/a> \u2013 <a href=\"https:\/\/www.thesslstore.com\/blog\/browsers-helping-https-phishing\/\">was only making things worse<\/a>.<\/p>\n<p>But even with all those factors tipping the scales in phishing\u2019s favor, <a href=\"https:\/\/www.thesslstore.com\/blog\/5-ways-to-determine-if-a-website-is-fake-fraudulent-or-a-scam\/\">a discerning eye could still spot a fake<\/a>.<\/p>\n<p>Not with a rogue certificate. A rogue certificate will trick users\u2019 web browsers into trusting the website despite it being a fake.<\/p>\n<span style=\"display:none\" class=\"tl-placeholder-f-type-shortcode_15135\"><\/span>\n<h2>How can a rogue certificate trick a user\u2019s browser?<\/h2>\n<p>Let\u2019s talk about the way that certificate-based authentication actually works. This isn\u2019t the validation that takes place during issuance, this is the check that a browser does when presented with a certificate upon arrival at a website.<\/p>\n<p>The checks are:<\/p>\n<ol>\n<li>Was the certificate signed by a trusted CA? Does the digital signature chain back to one of the roots in the trust store?<\/li>\n<li>Is this certificate still valid? When was it issued? <a href=\"https:\/\/www.thesslstore.com\/blog\/what-happens-when-your-ssl-certificate-expires\/\">When does it expire<\/a>? Are we still in that time frame?<\/li>\n<li>Has the certificate been revoked? This requires an <a href=\"https:\/\/www.thesslstore.com\/blog\/ocsp-stapling-best-method-checking-certificate-validity\/\">OCSP<\/a> or <a href=\"https:\/\/www.thesslstore.com\/blog\/what-is-onecrl\/\">CRL<\/a> check.<\/li>\n<li>Does the key pair match? Is the server in possession of the associated private key?<\/li>\n<\/ol>\n<p>Step 4 is sometimes referred to as proof of possession. And I say steps, that\u2019s just for reference \u2013 <em>let\u2019s not get too hung up on the terminology<\/em>. The browser will <a href=\"https:\/\/www.thesslstore.com\/blog\/difference-encryption-hashing-salting\/\">encrypt<\/a> some piece of throwaway data with the certificate\u2019s public key. Now, the public key is actually derived from the private key, which is why only that private key can decrypt that public key. This is what prevents spoof websites from just copying a legitimate site\u2019s SSL certificate and trying to present its public key as its own. That certificate&#8217;s public key wouldn\u2019t work because the server presenting the certificate doesn\u2019t have the private key.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-medium wp-image-7434\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Negative-Shield-e1537298060635-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Negative-Shield-e1537298060635-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Negative-Shield-e1537298060635.jpg 400w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>Ok, so now let\u2019s mix in a rogue certificate.<\/p>\n<p>Remember, a rogue certificate is a valid certificate that has come into the possession of a third-party \u2013 typically a malicious one. That means that the attacker actually has the private key.<\/p>\n<p>So when you arrive at a malicious website with a rogue certificate, your browser performs those four checks. It makes sure the certificate was signed by a trusted CA. It was. It makes sure the certificate is valid. It is. It checks if the certificate was revoked. It isn\u2019t.<\/p>\n<p>Now it\u2019s going to check proof of possession.<\/p>\n<p>It uses the public key associated with certificate to encrypt some data and the attacker, which has the associated private key, decrypts and returns it. As far as your computer system is concerned, this website is who it says it is.<\/p>\n<p>A user\u2019s computer never actually authenticates the server itself, it just authenticates the certificate. It\u2019s kind of like when you present a police officer with your driver\u2019s license. He\u2019s going to make sure that the picture on the license matches, that the license is valid, that it hasn\u2019t expired and he\u2019s going to call into the DMV to make sure it hasn\u2019t been revoked. If those all check out, he\u2019s going to accept the license as legitimate. He\u2019s not actually going to check your DNA and blood type to make sure it\u2019s you on a biological level, he\u2019s going off the documentation.<\/p>\n<p><a href=\"https:\/\/www.thesslstore.com\/blog\/how-pki-works\/\">PKI works<\/a> the same way. A rogue certificate isn\u2019t all that different from a forged passport or a faked identity in a spy film. It allows an attacker to operate under a false identity.<\/p>\n<h2>How do rogue certificates get issued?<\/h2>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-7432 alignright\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Encryption-Key-e1537298368681-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Encryption-Key-e1537298368681-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Encryption-Key-e1537298368681.jpg 400w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>Here is the million dollar question, how do rogue certificates happen? Well, there are three primary sources of rogue certificates:<\/p>\n<ul>\n<li>Rogue Certificate Authorities<\/li>\n<li>Breached Certificate Authorities<\/li>\n<li>Beating a CA\u2019s Domain Control check<\/li>\n<\/ul>\n<p>Let\u2019s start with certificate authorities going rogue and then we\u2019ll talk about the various exploits that have been used to get legitimate CAs to mis-issue certificates.<\/p>\n<h2>When Certificate Authorities go Rogue<\/h2>\n<p>There are a number of reasons a Certificate Authority may go rogue. It could be as a result of root compromise, it could be the result of unscrupulous management decisions or it could be that the CA issued an intermediate root to an untrustworthy company.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-medium wp-image-7431\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Digital-Unlocked-e1537298389540-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Digital-Unlocked-e1537298389540-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Digital-Unlocked-e1537298389540.jpg 399w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>That\u2019s what ultimately led to the downfall of <a href=\"https:\/\/www.thesslstore.com\/blog\/browsers-distrust-procert\/\">CNNIC<\/a>, a Chinese company that had a trusted root that was revoked by Google (and other root stores) in 2015. CNNIC had issued an intermediate root to an Egyptian company, MCS Holdings, that misused the intermediate to sign malicious certificates for websites like Google and Microsoft, that were then installed on a MITM proxy server.<\/p>\n<p>Remember, because the intermediate root was signed with the private key of a trusted root, any endpoint certificate signed by the intermediate is automatically trusted by browsers. That meant Google and Microsoft had to scramble to distrust CNNIC&#8217;s roots, invalidating thousands of legitimate certificates in the process.<\/p>\n<p>A similar situation occurred in 2013 when <a href=\"https:\/\/www.thesslstore.com\/blog\/browsers-distrust-procert\/\">ANSSI<\/a>, which is the French National Cybersecurity Agency, issued an intermediate root to a sub-CA that then misused it to issue fraudulent certificates, also as part of a MITM proxy operation.<\/p>\n<h2>When Certificate Authorities are Breached<\/h2>\n<p>Breaching a CA is another method for getting rogue certificates issued. If attackers can break into the CA\u2019s network and compromise the private key they can get certificates mis-issued. This happened twice in 2011, with the more notable case being that of DigiNotar, a Dutch CA that was breached that July.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-7430 alignright\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Phishing-Site-e1537298425732-300x292.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"292\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Phishing-Site-e1537298425732-300x292.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Phishing-Site-e1537298425732.jpg 399w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>In this case, Iranian hackers compromised the CA\u2019s private key after gaining entry to the network via SQL injection. That was the beginning of the end for the Dutch CA. The Dutch government took over in September of 2011 and by the end of the month had declared DigiNotar bankrupt. The major root stores removed the DigiNotar roots, which in effect revoked all DigiNotar certificates the world over (they could no longer be chained back to a trusted root).<\/p>\n<blockquote><p>\u201cTo be able to use such a certificate, the hacker would need to intercept traffic and insert their own fake certificate in a Man-in-the-Middle (MitM) attack,\u201d <a href=\"https:\/\/www.techrepublic.com\/blog\/it-security\/compromised-certificate-authorities-how-to-protect-yourself\/\">wrote Tech Republic\u2019s Patrick Lambert<\/a>. \u201cIn the case of DigiNotar, that&#8217;s exactly what happened. The Iranian government has proxy servers through which all of the country traffic transits. With such a certificate, it meant that they can suddenly access every single user&#8217;s Gmail account, bank account, or any encrypted connection they want in the country, since they had the private key of a trusted authority, and could then issue CSRs for any website they wanted.\u201d<\/p><\/blockquote>\n<h2>Beating a CA\u2019s Domain Control Check<\/h2>\n<p>Finally, we have exploits that can trick a CA into issuing a rogue certificate without having to compromise the private key itself. Now, let me preface by saying that neither of these exploits would be easy to pull off \u2013 at least for the average internet user.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-medium wp-image-7429\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Mis-Issuance-e1537298463450-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Mis-Issuance-e1537298463450-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Mis-Issuance-e1537298463450.jpg 400w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>The first is now outmoded because the industry has mandated the use of <a href=\"https:\/\/www.thesslstore.com\/blog\/difference-sha-1-sha-2-sha-256-hash-algorithms\/\">SHA-2<\/a> as the hashing algorithm in X.509 certificates. So, unless you\u2019ve got a working PKI that still uses <a href=\"https:\/\/www.thesslstore.com\/blog\/difference-encryption-hashing-salting\/\">MD5<\/a>, this won\u2019t work.<\/p>\n<p>But the idea behind it is to create a collision using the MD5 algorithm. Hashing is the practice of <a href=\"https:\/\/www.thesslstore.com\/blog\/difference-encryption-hashing-salting\/\">mapping data of any length to a fixed length output<\/a>.<\/p>\n<p>Ideally, no two hash values should ever be the same. When they are, it\u2019s called a collision.<\/p>\n<p>Per the abstract on <a href=\"https:\/\/capec.mitre.org\/data\/definitions\/459.html\">CAPEC-459<\/a>:<\/p>\n<blockquote><p>An adversary exploits a weakness in the MD5 hash algorithm (weak collision resistance) to generate a certificate signing request (CSR) that contains collision blocks in the &#8220;to be signed&#8221; part. The adversary specially crafts two different, but valid X.509 certificates that when hashed with the MD5 algorithm would yield the same value. The adversary then sends the CSR for one of the certificates to the Certification Authority which uses the MD5 hashing algorithm. That request is completely valid and the Certificate Authority issues an X.509 certificate to the adversary which is signed with its private key. An adversary then takes that signed blob and inserts it into another X.509 certificate that the attacker generated. Due to the MD5 collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary&#8217;s second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.<\/p><\/blockquote>\n<p>The second exploit (and no, this isn\u2019t an exhaustive list) is a more recent one and involves <a href=\"https:\/\/www.thesslstore.com\/blog\/german-researchers-circumvent-domain-validation\/\">DNS cache poisoning<\/a>. We actually covered this earlier this month. Basically, the attack is initiated with a DNS request, the attacker needs to craft a correct DNS response before the real one from the nameserver arrives. When the CA performs the domain validation checks, it receives answers from the attacker\u2019s DNS server.<\/p>\n<p>In order for the attack to work the DNS response needs to be broken down into fragments, which are then injected to trick the CA into issuing the requested certificate. While the first fragments in the response actually contain the valid DNS challenge-response fields, the rest contains whatever information the attacker needs to get the certificate.<\/p>\n<p>This attack hasn\u2019t been seen in the wild yet, it was discovered by a group of German researchers that will present it at a security conference next month.<\/p>\n<h2>How can my company avoid rogue certificates?<\/h2>\n<p>There are a number of different steps you can take, as well as some exciting industry initiatives that should also help alleviate some of these concerns. Let\u2019s start with the industry initiatives and then we\u2019ll get into some certificate management advice.<\/p>\n<h2><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-7436 alignright\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Certificate-Scanning-e1537298267669-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Certificate-Scanning-e1537298267669-300x300.jpg 300w, https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Certificate-Scanning-e1537298267669.jpg 399w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/>Certificate Transparency<\/h2>\n<p>One of the initiatives Google has been most passionate about is <a href=\"https:\/\/www.thesslstore.com\/blog\/certificate-transparency\/\">Certificate Transparency<\/a>. Earlier this year, <a href=\"https:\/\/www.thesslstore.com\/blog\/certificate-transparency-april-30-2018\/\">CT logging became mandatory<\/a>. In order for a certificate to be trusted, it must be properly logged. What that means is that every time a Certificate Authority issues an SSL\/TLS certificate it is obligated to submit record of that issuance to a third party Certificate Transparency log. The rules for logging vary by company, but <a href=\"https:\/\/www.thesslstore.com\/blog\/apple-certificate-transparency-october-15\/\">most browsers require that certificates be added to at least two CT logs<\/a>.<\/p>\n<p>By doing this, it gives companies greater oversight. Using tools like <a href=\"https:\/\/www.thesslstore.com\/blog\/facebook-certificate-transparency\/\">Facebook\u2019s log viewer<\/a>, it\u2019s possible to see what certificates have been issued for what domains. And upon encountering any rogue certificates, request their revocation. Unfortunately, revocation is something that the whole SSL\/TLS ecosystem needs to address, but CAs do have obligations to revoke certificates within a certain time-frame when it&#8217;s requested.<\/p>\n<h2>CAA Records<\/h2>\n<p>A CAA or Certificate Authority Authorization is a DNS record that serves as an internet security policy mechanism. Basically, a CAA dictates which Certificate Authorities are authorized to issue certificates for your organization. A CAA record can set policy for specific host names or an entire domain. CAA records are specified as <a href=\"https:\/\/tools.ietf.org\/html\/rfc6844\">RFC 6844<\/a>.<\/p>\n<p>By restricting issuance to just a handful of CAs, you can limit some of the risk posed by a rogue certificate. <a href=\"https:\/\/www.thesslstore.com\/blog\/caa-checking-mandatory\/\">All CAs are required to make a DNS lookup for CAA before issuing<\/a>. Failing to check it constitutes mis-issuance and most CAs are loath to mis-issue. <a href=\"https:\/\/www.thesslstore.com\/blog\/mozilla-distrusts-procert\/\">Google has literally killed for less<\/a>.<\/p>\n<h2>More tips for avoiding Rogue Certificates<\/h2>\n<p>We say it all the time, but the most important thing for Enterprises is visibility. You need a <a href=\"https:\/\/www.thesslstore.com\/partner\/enterprise-solutions.aspx\">certificate management tool<\/a> that allows you to inventory all of your digital certificates, track expiry and reissues, automate certain functions and just generally allow you to control your PKI through one interface.<\/p>\n<p><strong><em>RELATED: <\/em><\/strong><a href=\"https:\/\/www.thesslstore.com\/blog\/pki-certificate-management-mistakes\/\"><em>11 critical mistakes to avoid when setting up your PKI<\/em><\/a><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-7437 alignleft\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/Digital-Lock-e1537298160910-300x300.jpg\" alt=\"what is a rogue certificate\" width=\"300\" height=\"300\" \/>Beyond good certificate management habits, here are a few other pieces of actionable advice:<\/p>\n<ul>\n<li>Patch regularly, specifically browser and Operating System patches. This is good security hygiene in general, (<a href=\"https:\/\/www.thesslstore.com\/blog\/equifax-data-breach-learn\/\">just ask Equifax<\/a>) but it\u2019s especially important in this context because this is the way that <a href=\"https:\/\/www.thesslstore.com\/blog\/macos-trusted-root-certificates\/\">updates to root stores<\/a> are rolled out. When a Certificate Authority is compromised or mis-issues badly enough the most direct way to triage the problem is to <a href=\"https:\/\/www.thesslstore.com\/blog\/how-to-remove-a-root-certificate\/\">remove the affected roots<\/a>. This automatically distrusts all certificates that were signed by that root or one of its descendants. When this happens, your organization is vulnerable until it patches and updates its root stores.<\/li>\n<li>Limit asset exposure, meaning reduce attack surface by enacting strong CAA policies that restrict issuance to only a handful of CAs. It\u2019s also important to create organizational policies for the issuance and cycling of digital certificates so that everyone has a clear idea of the stakeholders in the issuance process. Having too many employees involved \u2013 too many cooks in the proverbial kitchen \u2013 is only going to confuse things. So streamline by restricting what CAs can issue for what domains and which parties are authorized to request issuance in the first place.<\/li>\n<li>Perform regular scans. There are tons of tools that can help you scan CT logs, revocation lists, network notaries and locally stored databases. These scans will assist you in finding rogue certificates, from there you just need to contact the right CA and get the certificates revoked.<\/li>\n<\/ul>\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<p>And here\u2019s one last piece of advice on a personal level, make sure your browser is configured to check for revocations. Certificate Revocation Lists and Online Certificate Status Protocol (OCSP) logs are maintained by CAs and tell your browser when it shouldn\u2019t trust a certificate. Make sure that if an OCSP call fails, that your browser treats the certificate as untrustworthy, too.<\/p>\n<p>Well, there\u2019s your rundown. The next time someone asks \u201cWhat is a rogue certificate?\u201d Point them in this direction.<\/p>\n<p><em>And as always, feel free to leave any comments or questions below.<\/em><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-7276 size-full\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568.jpg\" alt=\"Hashed Out by The SSL Store is the voice of record in the SSL\/TLS industry.\" width=\"1559\" height=\"407\" srcset=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568.jpg 1559w, 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-1024x267.jpg 1024w\" sizes=\"auto, (max-width: 1559px) 100vw, 1559px\" \/><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A rogue certificate can wreak havoc on your company \u2013 here\u2019s how to prevent that. One of the most frequent questions we get asked is, \u201cwhat is a rogue certificate?\u201d&#8230;<\/p>\n","protected":false},"author":6,"featured_media":7428,"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":[228,8586],"class_list":["post-7425","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-everything-encryption","tag-pki","tag-rogue-certificates","post-with-tags"],"views":27083,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-215749885.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/7425","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=7425"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/7425\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/7428"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=7425"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=7425"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=7425"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}