Well, they&#x27;re hitting your web server because you don&#x27;t want a hard-required client certificate. (I&#x27;ve administered a server relying on a larger deployment of client certs than OP&#x27;s; browser compatibility is a mess, and `SSLVerifyClient require` is a mistake.)<p>Yes, you can set things up on the server side so that it hits a static page instead of your web <i>application</i>. But you can do that with the JS-based solution too: have it send you to a login page with a signed query-parameter or similar, and verify that query parameter in the web server configuration. If it fails &#x2F; doesn&#x27;t exist, deliver a static site that includes the necessary JS to do the login.<p>Your web server will need to verify a signature or MAC there, but this is way less attack surface than the usual client-cert processing code in SSL stacks (which processes untrusted keys and signatures). Removing that code will be an equal or greater security win.<p>Basically, if there is interest in engineering a good application-level solution instead of relying on the transport-level one, it can absolutely be done. (I do freely admit there isn&#x27;t anything that can be used out-of-the-box today, to my knowledge.)