It's a little difficult to get to this file though.

Why is that? If you can go get the cmd, generate_cert.go is already available too.

Why is that?

Say I want to ask end users to run the generate_cert.go file to get local certs. With every other Go binary I check for it on the $PATH and go get it otherwise, which assumes only that you have a Go binary locally.

Compare this in a Makefile:

STATICCHECK := $(shell command -v staticcheck)

vet:
ifndef STATICCHECK
	go get -u honnef.co/go/tools/cmd/staticcheck
endif
	staticcheck ./...

with

generate_cert:
    go run "$$(go env GOROOT)/src/crypto/tls/generate_cert.go"

The latter can break because GOROOT is not defined, GOROOT has multiple entries, the user doesn't have the Go standard library locally, etc. etc.

@kevinburke I have nothing much to add except point you to a repo that I made a year ago; it does exactly what you want and I use it a lot locally https://github.com/odeke-em/ssg go get github.com/odeke-em/ssg && ssg --host localhost

go run "$$(go env GOROOT)/src/crypto/tls/generate_cert.go"

I have done this, literally in a makefile, and would agree it would be nice to have it as a seperate command. I am guessing it's like this because no one really wants to support it, since it just primarily used for testing? idk if putting it behind something similar to "httptest" to reflect that is the use would help with that matter.

If only somebody in this thread had a github account.

Emmanuel's already put this in a Github repo, if that's all we want to do.

I guess my worry with that is missing out on a change to the code in generate_cert.go. Specifically I am assuming that the minimum size or recommended curves will change over time, and worried that the external maintainer won't pick that up.

If we moved this file to e.g. golang.org/x/crypto/cmd/generate_cert and repointed all of the internal code references, there would only be one copy of the code.

Once it's go-gettable, then people will keep asking for features. We already have openssl to generate certs, which is what most people use I believe. It's not clear why we need this little program.

And it would be the first "package main" in x/crypto.

And the underscore might not be idiomatic.

But if @agl as owner of x/crypto doesn't mind, sure.

I don't think we have committed to writing a cert generation tool appropriate for production use. The generate_cert.go program is a simple program for writing tests. If we package up generate_cert.go, it implies more support than we are committed to at the moment. For production use, people can use openssl or any other generator explicitly targeted at that use.

FYI generate_cert.go has problems when you start a server with it and try to validate the configuration using OpenSSL. I wrote a program that generates a root CA and a leaf off of that CA, which validates. I also tried to add instructions for it across a wide variety of languages. You can find it here. https://github.com/Shyp/generate-tls-cert

@kevinburkeshyp we don't monitor closed issues, if that's still a problem, please open a new issue.