Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/crypto/acme/autocert: Expose Subject Alternative Names in manager.GetCertificate #28158

Open
anurag opened this issue Oct 11, 2018 · 5 comments
Open
Milestone

Comments

@anurag
Copy link

@anurag anurag commented Oct 11, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.11.1

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

darwin,amd64

autocert has a certRequest method which can take Subject Alternative Names as input here, but the Manager does not expose a way to pass these values through GetCertificate or otherwise. In theory, manager.ExtraExtensions could enable this but it would require creating a new manager instance for every request which doesn't seem right. Is there another way to use autocert to generate certificates with SANs?

@gopherbot gopherbot added this to the Unreleased milestone Oct 11, 2018
@x1ddos
Copy link

@x1ddos x1ddos commented Oct 11, 2018

hm.. not sure I understand. "auto" part in "autocert" is the whole point of it to request certs automatically during GetCertificate based on what a client sends in SNI.

what would you want to add to SANs manually?

@anurag
Copy link
Author

@anurag anurag commented Oct 11, 2018

Good question. We'd like to upload autocert-generated certificates to CDNs which terminate client SSL. A lot of CDNs (like AWS Cloudfront) allow uploading just one certificate per site, so we want to issue a certificate for example.com and add www.example.com as a SAN so the CDN can terminate SSL for both endpoints with a single certificate.

@x1ddos
Copy link

@x1ddos x1ddos commented Oct 11, 2018

Right. It seems like what you want is to pre-generate a cert for all hosts what clients will be connecting to. By "pre-generate" I mean in the context of autocert, because the way it works is it requests a certificate issuance during an in-flight TLS request if no certs are already available.

Maybe something like dns-01 would be more suited for this use case? Check the discussion and my example in #23198 (comment).

@anurag
Copy link
Author

@anurag anurag commented Oct 11, 2018

We considered DNS-01, but we don't control DNS for our users' sites. HTTP-01 or TLS-ALPN challenges work because our users add a CNAME record pointing to a an endpoint we host (which is currently backed by autocert). We could ask them to add an additional CNAME record for _acme-challenge, but we'd rather not. Our autocert setup works for now because we don't have the single certificate limitation, but using CDNs throws a wrench in the works. It's okay if this isn't what autocert is meant for; we can use cert-manager because we operate kube clusters.

@philips
Copy link

@philips philips commented Jun 29, 2019

I am going to just fork autocert and change HostPolicy to this: type HostPolicy func(ctx context.Context, host string) (cn string, san []string, error)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants