<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CSR on DevLogs</title><link>https://blog.param.sh/tags/csr/</link><description>Recent content in CSR on DevLogs</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 02 May 2026 07:07:33 +0530</lastBuildDate><atom:link href="https://blog.param.sh/tags/csr/index.xml" rel="self" type="application/rss+xml"/><item><title>CSR Formats, X.509 Standard, and more...</title><link>https://blog.param.sh/posts/other-components-of-tls/</link><pubDate>Sat, 02 May 2026 07:07:33 +0530</pubDate><guid>https://blog.param.sh/posts/other-components-of-tls/</guid><description>&lt;h1 id="what-are-x509-certificates"&gt;
 What are X.509 certificates?
 &lt;a class="heading-link" href="#what-are-x509-certificates"&gt;
 &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;
 &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;
 &lt;/a&gt;
&lt;/h1&gt;
&lt;p&gt;A X.509 is the standard certificate format of signed certificate which contains details like the server’s public key, the domain name it’s valid for, who issued it, how long it’s valid etc.&lt;/p&gt;
&lt;p&gt;You don’t really need to memorize the structure, but the idea is that every certificate on the internet follows the same blueprint, so browsers know exactly where to look for things like the public key, issuer, and signature. It’s what makes the whole system interoperable.&lt;/p&gt;</description></item><item><title>The Chain of Trust: Signing TLS</title><link>https://blog.param.sh/posts/chain-of-trust-signing-tls/</link><pubDate>Sat, 25 Apr 2026 18:23:33 +0530</pubDate><guid>https://blog.param.sh/posts/chain-of-trust-signing-tls/</guid><description>&lt;h1 id="the-trust-problem"&gt;
 The Trust Problem
 &lt;a class="heading-link" href="#the-trust-problem"&gt;
 &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;
 &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;
 &lt;/a&gt;
&lt;/h1&gt;
&lt;blockquote&gt;
&lt;p&gt;If you haven&amp;rsquo;t been following along, this is part of the series &lt;a href="https://blog.param.sh/series/encryption-in-transit" &gt;Encryption in Transit&lt;/a&gt;.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;So far, everything sounds nice in theory. You and a server has a public key, you use it to create a pre-computed symmetric key and talk securely, done.&lt;/p&gt;
&lt;h3 id="but-how-do-you-even-know-that-public-key-belongs-to-the-server-you-think-it-does"&gt;
 But, how do you even know that public key belongs to the server you think it does?
 &lt;a class="heading-link" href="#but-how-do-you-even-know-that-public-key-belongs-to-the-server-you-think-it-does"&gt;
 &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;
 &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;
 &lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;Like, imagine you’re trying to connect to your bank. You ask for its public key, and you get a response containing the public key. Cool. But how do you know it&amp;rsquo;s really the bank you&amp;rsquo;re talking to? What if there is an actual attacker sitting and intercepting every request you make to your bank? Which means if you go to &lt;code&gt;bank.com&lt;/code&gt; it is actually an attacker trying to portray itself as &lt;code&gt;bank.com&lt;/code&gt; and never letting your request reach to the ACTUAL &lt;code&gt;bank.com&lt;/code&gt;. In this case, they can just hand you their public key, you happily encrypt everything with it, and now they’re reading all your traffic while pretending to be the bank.&lt;/p&gt;</description></item></channel></rss>