TLS key share versus client certificate: which one logs in?

Carrying a public key-exchange value in a handshake is not the same event as a client logging in. One establishes cryptographic state for the connection; the other states who the client is, and it only happens when the server asks for it and the exchange supports it. Treating the first as the second leads to bad conclusions about what a VPN does and does not hide. Read the messages, then decide which of four properties you actually observed.

Two objects that look alike in a capture

A TLS 1.3 client can contribute key-exchange material in its first flight without presenting any certificate. That contribution is public by design, because the server needs it to derive the shared secret. A client certificate is a different message, sent only after the server requests one. It carries an identity that the server then verifies, and mutual authentication is a decision the server makes rather than a property the cipher suite implies. Application identity is a third thing entirely: a login form, a bearer token, a cookie. None of those appear in the handshake, and all of them survive a change of network path.

The four rows are independent. A connection can have rows one and two, skip row three, and still carry row four in a cookie header.

Decide what a captured handshake can prove

From the handshake alone, an observer learns the negotiated version, the cipher suite, the server's certificate and the public key-exchange values. That is enough to fingerprint a client implementation and to see which server was contacted. What it does not yield is the private state needed to decrypt the connection, whose secrecy rests on the ephemeral exchange rather than on the public share. It also does not yield an account identity, which was never in the handshake to begin with.

So the honest conclusion is narrow: no client certificate was presented in this exchange. It is not that the client sent nothing linkable, and it is certainly not that the session carried no identifier.

Read the messages instead of the cipher name

Ask the server what it requests, rather than inferring from the suite. A TLS 1.3 handshake that includes a certificate request is visible in the transcript, and its absence is equally visible.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Then repeat with a client certificate configured, and compare. The second run should show the certificate being sent and accepted; the first should show none, which is the concrete difference the argument is about.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

If you only need the ordinary browsing case, the verbose client output is enough to see the protocol version, the verification result and whether a client certificate was offered. A server that never sends a certificate request cannot have received one.

Where resumption changes the answer

TLS 1.3 resumption uses tickets associated with secret state, so a later connection can complete without a full certificate exchange. That reduces what an observer sees and changes what the transcript proves. It does not create an identity where none existed. A resumed session still belongs to the same application session, and any cookie or token in that session remains the identifier that matters.

This is why a privacy review that stops at "no client certificate" misses the interesting part. The question to ask is which party holds a stable identifier, not which message was absent from one handshake.

Record four properties, not one verdict

Write down key agreement, server verification, client authentication and application identity as four separate lines, with the evidence for each. That inventory survives changes of protocol version, and it makes an argument about privacy checkable by someone else. Then add what the network path contributes. A VPN changes the source address a service observes; it does not remove a login, a cookie or a device fingerprint the application already holds.

Record the connection's negotiated version and the certificate request outcome together, because that pair is what a reviewer needs to reproduce your conclusion without a capture of their own.