Is there any 100% transparent way to set up client side TLS certs from a web browser?

Question

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.)

Questions:

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.

Edit:

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.

Answer 1

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.