There&#x27;s a fundamental problem with client certs as currently implemented in browsers as well as the &lt;keygen&gt; tag: these certificates aren&#x27;t origin-bound and violate the same-origin policy.<p>The method of authorizing client certs without using the same-origin policy is the source of the horrible UX problems: ask the user (often without a &quot;remember this choice&quot; checkbox, so users were asked every session)! Determining which certificate to use can be difficult depending on the subject&#x2F;issuer, and in general this is a terrible choice to ask a user to make.<p>The problem gets a <i>lot</i> easier if you use origin-bound certificates:<p><a href="http:&#x2F;&#x2F;www.browserauth.net&#x2F;origin-bound-certificates" rel="nofollow">http:&#x2F;&#x2F;www.browserauth.net&#x2F;origin-bound-certificates</a><p>With origin-bound certs there&#x27;s a clear and unambiguous answer as to what cert to use for a given origin by-design. These certs can either be dynamically provisioned in a browser or device-locked to e.g. a Yubikey U2F token. There&#x27;s no need to ask the user anything more than to push the button on their hardware token if they have one. Otherwise the process is completely automatic.<p>I really don&#x27;t think efforts to use in-browser client cert authentication that don&#x27;t respect the same-origin policy are going to get anywhere because of this problem.