Edit #2:

It seems the answer to Q#1 is "No" (which suggests I would need to look for some other solution, which is something I can do on my own, please don't spend time making suggestions for that) and that makes Q#2 the thing I'm still seeking information about.

The functionality in question seems sufficiently useful, and is sufficiently obvious, that it's omission suggests to me that there may be something interesting going on that prevents it from being offered. If anyone knows that why, I'd like to find out about it. (Unless it's "politics", in which case I have no interest in knowing any more than that.)


  1. Is there a way to do "this thing I want to do"?
  2. If not, why not?
    • Is there some subtle security issue with it?
    • Is it too easy to abuse?
    • Are there better alternatives for client tracking?
    • Are the benefits over existing options not enough to warrant the effort of adding it to the relevant standards?

"This thing I want to do":

TLS provides the ability for the client to authenticate itself via a certificate signed by a CA that the server claims to trust. This seems like it would be a rather robust way to implement client/session identification (as distinct from user identification) that could then be used as a basis for application logins and what not. This could have very similar semantics to cookies, but would be strictly better because the sensitive values are never available without access beyond what the browser normally gives.

Some initial research seems to suggest there isn't a way to do this without some degree of user interaction, furthermore, it seems a lot of the moving bits that would be involved have been changed so as to go out of their way to make it impossible.

What I'm thinking I'd like to see is a process where a unknown, un-trusted, never before seen client contacts a server and before the first page finishes loading (and without user interaction) constructs and installs a client side x.509 certificate with an opaque identity (e.g. some random number or fingerprint; the server may not know who you are, but it can know it's the same anonymous someone) that any further HTTPS request will include. From there any future authentication/access control steps can be pinned to that cert rendering it them non-transferable.

It looks like there used to be a <keygen /> tag in HTML5, but it was deprecated/unimplemented/removed and all the proposed alternatives seem to require user interaction. For example depending on the OS cert-instillation process, expecting the user to provide a password for the public key, installing a plug-in or extension, having a hardware token, etc.


The goal isn't anonymity but rather something that can be setup with minimal prerequisites that gives an "identity" that can't be faked without a general compromise of the client. ("Already being on the other side of the airtight hatchway.") MITI proxies mandated by pointy-haired-IT, third party JS, overly permissive ACL's on the server side DB, full plain-text transcripts of all the network traffic ... even with any or all of those, an attacker shouldn't be able to impersonate the "identity".

Also, the question of "who is this identity really?" and "what should this identity be allowed to do?" are different questions that would/could be addressed later via traditional logins, some kind of SSO, MFA, bootstrapping to another cert with more fields, signed-cookies-binding-the-cert-to-a-grants-list, ... whatever.

  • What you describe as "want" is already a very specific technical detail, namely a X.509 certificate. Only what you want is not possible with current browsers. What you don't sufficiently describe is what security properties you actually need. My guess is that you have the following requirements: 1. some kind of client-side authentication anchor 2. which can not be sniffed or otherwise deduced even by an active man in the middle attack but 3. which can be verified by the server. Any other requirements? – Steffen Ullrich Jan 14 at 21:31
  • As best I can tell, an X.509 certificate used for client side authentication in TLS provides the security properties I need. The operational properties I want are to be able to configure that in any modern, (common), standards conforming browser without the requirement for user action beyond the original navigation to the page. -- It seems that effort has been made to remove that operational ability and now my question is why? – BCS Jan 14 at 21:48
  • I see. So you want a specific technical implementation (certificate) of an unspecified security requirement and then ask why this is not (or no longer) possible with current browsers, right? – Steffen Ullrich Jan 14 at 22:00
  • 1
    WRT: SubtleCrypto and 'Would JS running in the page be able to POST the private key somewhere?': With SubtleCrypto, private keys are stored in a cryptokey object. You can set the .extractable property on the cryptokey object to false, then this prevents the key from being exported from the cryptokey object, so javascript cannot even access the key. See crypto.stackexchange.com/questions/35530/… for more info. However, it is javascript, so the page has to load before the js can run. – mti2935 Jan 14 at 22:47
  • 1
    WRT Q#1, What you are describing sounds very similar to channel-bound cookies. See browserauth.net/channel-bound-cookies (and other pages at this site) for some interesting reading on this subject. – mti2935 Jan 14 at 23:24

What you're asking for is a hands-off, unauthenticated way to say "I'm the same client you saw yesterday". There's already an answer for that: cookies.

Adding self-issued client certificates adds a lot of complexity but solves no problems. There's nothing to trust on a self-signed certificate.

Adding CA-signed client certificates removes anonymity, because that's exactly what certificates are intended to do -- a certificate ensures you are who a trusted third party says you are.

Cookies, on the other hand, are issued by you, the server. You can hand out a big long random value as a user ID cookie (128 bits) and it will be impossible for anyone else to randomly guess that value. If you send the value out to a client yesterday, and get that same cookie back today, you know it came from the same client.

If you're afraid of the cookie getting hacked, it's up to you to improve your web site to remove vulnerabilities to exposing your cookie. Turn on HSTS. After every successful returning client logs in, generate and deploy a new cookie to them. Use session timeouts. Don't invite random 3rd party JavaScript to infest your web page. You are in control of that cookie -- protect it.

Bottom line: if you want client anonymity, don't try to add a client certificate into the mix. Certificates are antithetical to anonymity.

  • A self-signed certificate is different to a cookie. A cookie in your use case is essentially a shared secret, visible to a man in the middle. And a man in the middle might exist for a example in case of TLS interception in local antivirus or corporate firewalls - and these might actually be insecure or already hacked. Even a self-signed certificate is instead public key cryptography, i.e. no shared secret and thus no secret to intercept. Even more, use of client certificates in the context of TLS interception will make the TLS handshake fail, assuming that the server does not trust the MITM. – Steffen Ullrich Jan 14 at 20:56
  • Anonymity is not the goal, merely the starting point. I'd like a system that can, starting from no relationship, setup an "identity" that can't be faked without extraordinary access at the client. MITI proxy, third party JS or even a full plain-text transcript of all network traffic should make no difference. Associating that identity to some sort of access or persona is a step that would happen later. – BCS Jan 14 at 21:11
  • So you'd like a system that generates client certificate requests on demand, sends them to a CA for signing (typically using the payment to your credit account as proof of identity), then automatically installs the client certificate for use? That would solve so many real-world problems for me I'd probably be out of a job. – John Deters Jan 14 at 21:47
  • The CA used to sign the CSR would probably be owned by me; only I will ever be trusting it. And there is no requirement (yet) for proof-of-real-world-identity. I just need to trust that all requests using the same cert are by the same actor. – BCS Jan 14 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.