In TLS, neither the client nor server signs any content. The cryptographic signatures that are used in the initial handshake are meant for authentication: the client obtains some guarantee that it talks to the right server, and (if client certificates are used) the server obtains some guarantee that it talks to the right client. However, neither of these guarantees is transferrable: though the client knows that the data it gets comes from the server, the client gets no proof that could be shown to a third party. That's authentication, not non-repudiation.
Even if the client records everything pertaining to the whole connection (all data bytes sent and received, all the negotiated cryptographic keys, and so on), this proves only one thing: that, at some unspecified point in time, the server was, indeed, a TLS server, and has been involved in at least one TLS connection. Everything else, including all the data puportedly received and sent by the server, could have been fabricated afterwards, so it cannot be a proof (in the cryptographic sense).
Thus, you haven't found a way to "get the server's signature of the content it is serving" for the reason that this signature does not exist. If you want the server to sign things, this must be arranged at the protocol level, inside the TLS tunnel: have the server duly sign the data and send the signature as part of what TLS calls "application data". Of course the server will have to be aware of the operation, and this is not part as normal TLS (HTTPS) processing.
Alternatively, have some bailiff or a similar official connect to the server, obtain the data, and sign it himself, thereby guaranteeing (in a legal way) that the server indeed serves these data content.