This is not a golang specific question. But to set the stage: I am using golang and a tls client certificate.
The tls client certificate is configured as such:
cert := tls.Certificate{
Certificate: crtbytes,
PrivateKey: signer,
}
This works fine and tls is used, however each time the signers .Sign is called a UI prompt is issued requiring manual entry of the PIN for the signing. I have reviewed the system and there is no way to avoid this PIN prompt when signing, so the only alternative left is to somehow decrease the number of sign operations performed by tls.
The cert & tls is used for multiple HTTPS connections towards a limited number of servers.
Reading through the crypto/tls documentation I cannot find anything that could be useful.
Does the TLS specification support anything that would decrease the number of required signatures?
Typically, when you make a TLS connection, the server can request a client certificate, and if so, there will be a single signature on both sides. (If you're using HTTP/2, there will typically be a single connection in most cases.) It is possible (but not required) for the server to issue a session ticket, which it sends to the client, which the client can use in a subsequent session to resume that session without the overhead of the full key exchange process.
However, that session ticket is usually a set of keying material encrypted by a symmetric key on the server side, so using session tickets destroys the perfect forward secrecy of the connection, and thus, it weakens security. If the server is using OpenSSL, it also can reduce the security of the connection because a fixed algorithm is always used.
The client must also have state to store that session ticket and reuse it (browsers usually do, but other clients often do not), but within those constraints, this could be a possible solution to your problem, at the expense of perfect forward secrecy.
If the private key is stored in a security key of sorts, it may be possible to have the security key configured so it does not require a PIN. This still would require the presence of the security key since the keying material could not be extracted from it, but it would reduce the burden on the user. That might be a sufficient solution, although your question does imply that it's not possible in your configuration.
You could also configure your server to normally not require a client certificate, but from time to time (say, once a day), redirect the client to a site that does require the client certificate via a single sign-on mechanism (e.g., OpenID or SAML), which then authenticates the user.