<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Certificate Revocation on Nalar</title>
    <link>https://nalar.dev/tags/certificate-revocation/</link>
    <description>Recent content in Certificate Revocation on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 11 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/certificate-revocation/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Plan Certificate Revocation Before a Key Is Compromised</title>
      <link>https://nalar.dev/plan-certificate-revocation-before-a-key-is-compromised/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/plan-certificate-revocation-before-a-key-is-compromised/</guid>
      <description>&lt;p&gt;A TLS certificate can still be inside its validity period when you need clients to stop trusting it. The private key may have been exposed, an identity may no longer be valid, or an issuing system may have made a serious mistake. Waiting for the certificate to expire leaves a gap between &amp;ldquo;we know this credential should no longer be trusted&amp;rdquo; and &amp;ldquo;clients stop accepting it.&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;Certificate revocation is the mechanism for communicating that change before normal expiry. The difficult part is operational: revocation information has to reach the relying parties that make trust decisions, and their behaviour when that information is stale or unavailable may differ.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
