Unfortunately, the standard TLS protocol does not provide a non-repudiation mechanism. It works by using public key cryptography and key agreement to get both

Unfortunately, the standard TLS protocol does not provide a non-repudiation mechanism. It works by using public key cryptography and key agreement to get both parties to agree on a symmetric key, and then uses the symmetric key to encrypt the actual session data. Any party who knows the symmetric key can forge arbitrary data, and so a transcript of a TLS session, coupled with the symmetric key, is not proof of provenance. There are interactive protocols that use multi-party computation (see for example https://tlsnotary.org/ https://tlsnotary.org/) where there are two parties on the client side, plus an unmodified server. tlsnotary only works for TLS1.2. One party controls and can see the content, but neither party has direct access to the symmetric key. At the end, the second party can, by virtue of interactively being part of the protocol, provably know a hash of the transaction. If the second party is a trusted third party, they could sign a certificate. However, there is not a non-interactive version of the same protocol - you either need to have been in the loop when the data was archived, or trust someone who was. The trusted third party can be a program running in a trusted execution environment (but note pretty much all current TEEs have known fault injection flaws), or in a cloud provider that offers vTPM attestation and a certificate for the state (e.g. Google signs a certificate saying an endorsement key is authentically from Google, and the vTPM signs a certificate saying a particular key is restricted to the vTPM and only available when the compute instance is running particular known binary code, and that key is used to sign a certificate attesting to a TLS transcript). I'm working on a simpler solution that doesn't use multiparty computation, and provides cloud attestation - https://lemmy.amxl.com/c/project_uniquonym https://lemmy.amxl.com/c/project_uniquonym https://github.com/uniquonym/tls-attestproxy https://github.com/uniquonym/tls-attestproxy - but it's not usable yet. Another solution is if the server will cooperate with a TLS extension. TLS-N (https://eprint.iacr.org/2017/578.pdf https://eprint.iacr.org/2017/578.pdf) provides a solution for this. That provides a trivial solution for provenance.