Re: [go-nuts] Loading Certificate and Key from string not file for HTTPs server

[burak serdar]

On Mon, Sep 13, 2021 at 3:03 PM Sam Caldwell <ma...@samcaldwell.net> wrote:

Does anyone have any ideas of an easy path to load certificate and key files from a string rather than a file?

Use Case:

1. traditionally we all put a cleartext file on disk with our private key and public certificate.  If the server is breached, we just regenerate all the things and move on.

2. I would like to store my certificates and keys in a more secure location (AWS SSM Param store, Hashicorp Vault, etc.).

3. The certificate is only read from file at startup as best I can tell, and relocating certificates and keys to an encrypted store would (a) allow better auditing when the content is accessed, (b) restrict access to only authorized processes and (c)  make rotating keys and certificates a much easier process.

Analysis:

Current Functionality:

- We setup a server using ListenAndServeTLS() and pass in a filename for the certificate and key.

- In go1.17.1/src/net/http/server.go at 3066, tls.LoadX509KeyPair() loads is called.

- LoadX509KeyPair() exists at 230 in src/crypto/tls/tls.go and

   - It calls os.ReadFile() at 231 and 235.

Possible Solution:

- We cannot break existing things, and within the limitations of golang, it is probably the least-disruptive solution to add a new ListenAndServeTLSFromVar() which would functionally do everything ListenAndServeTLS() does, but instead of reading a file, it would instead accept the input string as the certificate/key content.

- Alternatively ListenAndServeTLSFromVar() would accept a boolean parameter which would determine if certificate and key parameters are filenames or content strings.  in this case, ListenAndServeTLSFromVar() would support both filenames and content string use cases and provide a path to unifying the approach if the community begins to adopt the use case identified above in large numbers.

You can already do this by creating an http.Server{} with a tls.Config initialized from the certificates you have. You have to decode and parse the certificates from strings to create the tls.Config.

 

Conclusion:

I'm willing to do the work and contribute the code to implement the above, but I wanted to solicit opinions first.  Ideally the functionality exists already and I am reinventing a wheel.  In that case, please point me in the right direction so I can focus my efforts on my current project.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6e283ce3-7802-4765-9fd3-156d01c65bbbn%40googlegroups.com.

[Sean Liao]

It's only 3 lines excluding error handling if you just want to use a static string.

And you'll likely want to setting up your own http.Server anyway to have control over timeouts (and also your own mux to prevent leaking debug handlers).

In practice you may actually want o use crypt/tls.Config.GetCertificate instead, to allow your server to update certs from your secret store without a restart.

On Friday, October 8, 2021 at 3:52:29 PM UTC+2 Sam Caldwell wrote:

Sorry for the delayed response.  I needed to noodle on this option and talk to some of the devs who would need to implement this.

1. Setting up an http.Server{} and tls.Config will work.  But it is a lot of effort for devs who want to focus on the business logic.

2. This creates more code the golang users (devs) need to implement and maintain...which disincentivizes a non-file-based approach.

I've created my own library to do what is suggested in this thread, but I'd say that as a community we should pursue a better option.