I'm using a GlobalSign EST Go library that provides an implementation of the RFC 7030 (EST).

So far doesn't provide any function to generate a CSR at runtime and therefore include the TLS-unique value in the CSR before enrolment.
I might use the crypto package for that along with a little code tweaking.

However there is something I noticed while debugging the simple functions such as getting the CACerts or even enrolling an existing CSR

  1. I can't have access to the TLS-unique value from the GlobalSign client implementation, I guess that would be part of the code tweaking I mentioned earlier

  2. And this might be the solution, but not sure how to make use of it, the context. I was hoping to find the http context and eventually get the information of TLS-unique value in there. Unfortunately, whether I use context.TODO() or .Background(), it's empty in my debugging.

Also, that 2nd point made me wonder, is it supposed to be like that?
I thought I should include that value in the form of the challenge password attribute of the CSR, and that CSR is then sent to the server, and the server is going to verify it's the same TLS unique value. Because any http request will generate a new TLS-unique value. Or at least, that's my interpretation of the RFC 7030 - section 3.5.

If my understanding is correct, then there is something wrong with my EST go package, and I still don't know how I could get that value from the client during the enroll operation.

If there are any other Go libs that implement the EST protocol with more flexibility, you're welcome to share.

  • In section 3.5 of the RFC, it states that the tls-unique value is base64 encoded and placed into the CSR's challenge password field. I'm not familiar with the GlobalSign EST Go library, but if there is no way to do this with this library, then perhaps another tool can be used to create the CSR with the tls-unique value in the challenge password field. For example, openssl can do this progamatically.
    – mti2935
    Nov 28, 2023 at 21:42
  • The issue is not generating the CSR programmatically, but fetching the TLS-unique value in the right time, i'm thinking : during TLS handshake, before the client sends the CSR. The go-csr can do the job too (openssl too).
    – MoBe
    Nov 29, 2023 at 8:33

1 Answer 1


I might have a workaround to my own question, on a different stack platform.
In my case, it requires small changes in the EST Go lib I'm using to meet the requirement.

But since we're just talking about the TLS unique value here, it can be fetched from the http response through the field http.Response.TLS.TLSUnique.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .