The net/http go package has a type request that defines a field TLS holding the ConnectionState. Although, the last statement from the description says it's ignored by the HTTP client. I also checked that while debugging and it is nil.
I need to get the value TLSUnique from that connection state (or somewhere else), so that I can include it in my certificate request, aka CSR, before I can enroll/send it to the server.
The server is out of scope of my question. My concern is about the client.
Then the server receives the request and would check the signature of the CSR along with TLS-unique value, proving that the same client with whom the TLS connection has been established with, is the same who signed the CSR.
This is something that comes from the RFC 7030 - section 3.5 (EST protocol)
[What I'm using]
I'm experimenting the GlobalSign EST Go package, and they don't seem to include this functionality.
Their EST-client seems to create an http client for every EST operation, I thought I could change that behavior and have one client from which we send all requests.
However, since the client accepts a RoundTripper interface, i can't use information of the underlying connection outside of the implementation.
One way of doing it requires a small change from the global sign EST package.
Like I said earlier, the current implementation creates a new http client for every EST operation (CACerts, CSRAttrs, Enroll etc.)
1- Let's have one http client for all EST operations.
2- Either way, we're gonna need to make a call to get the CA certificates before enrolling a CSR.
3- The http response to any client request exposes the field http.Response.TLS.TLSUnique.
4- Let the client inlcude it in the certificate request, sign it and enroll it.
I'm not sure if there are any security concerns with this when I think about the global sign EST package and why they chose to create a new http client every time.
(unless it's just examples waiting to be used according to the user's will)