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: acme: identifier authorization failed #17263
Comments
Are you serving your web server at bleh.zekjur.net:443 as well as 60667? |
I think it should be possible to validate tls-sni challenge on a non standard port. acme/autocert currently ignores the port and let's encrypt assumes the default, 443, I believe. Will do some experiments tomorrow and then create a CL. |
Thanks for clarifying. I indeed only serve on 60667 and intend to keep it that way. I’d be happy to test a change to verify the problem is addressed. |
@x1ddos Any updates on this issue? Thanks. |
@stapelberg I've realized tls/Config.GetCertificate only takes ClientHelloInfo which doesn't have port info, only host name. Have you tried doing it manually? Not sure it'll work, but something like this: m := autocert.Manager{
Prompt: autocert.AcceptTOS,
HostPolicy: autocert.HostWhitelist("example.org"),
}
getCert := func(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
return m.GetCertificate(...)
}
s := &http.Server{
Addr: ":60667",
TLSConfig: &tls.Config{GetCertificate: getCert},
}
s.ListenAndServeTLS("", "") Otherwise, it'll have to wait until a Listener is implemented, as discussed in #17053. |
Oh wait, neither of my suggestions would work. Let's Encrypt (and the spec, for that matter, it seems) supports only port 443 for You'd have to obtain the certs in some other way (use See https://community.letsencrypt.org/t/letsencrypt-doesnt-work-for-different-ports/17519 and https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419 @bradfitz I think this issue can be closed now. |
Thanks for looking into this.
My reading of https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-7.3 (which outlines the So, is this a Let’s Encrypt limitation or an ACME limitation? If the latter, I think we should update the spec to clearly state that (and its intention). If the former, we should file a tracking bug at LetsEncrypt to lift that limitation.
Is there by any chance a code example explaining how to use the |
There's no way to specify the port, AFAIK.
import "golang.org/x/crypto/acme"
key, err := rsa.GenerateKey(rand.Reader, 2048)
if err != nil {
log.Fatal(err)
}
client := &acme.Client{Key: key}
ctx := context.Background()
a, err := client.Authorize(ctx, "example.com")
if err != nil {
log.Fatal(err)
}
if a.Status == acme.StatusValid {
// Client.Key is already authorized for example.com.
// Skip DNS record provisioning and go to client.CreateCert
}
// Find dns-01 challenge in a.Challenges.
// Let's assume the var name is challenge.
tok, err := client.DNS01ChallengeRecord(challenge.Token)
if err != nil {
log.Fatal(err)
}
// Provision tok value under _acme-challenge.example.com as a TXT record.
// Remember to defer unprovision().
// Once provisioned and propagated in DNS:
if _, err := client.Accept(ctx, challenge); err != nil {
log.Fatal(err)
}
a, err = client.WaitAuthorization(ctx, a.URI)
if err != nil {
log.Fatal(err)
}
if a.Status != acme.StatusValid {
log.Fatal("domain authorization failed")
}
// Create the certificate.
priv, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
if err != nil {
log.Fatal(err)
}
req := &x509.CertificateRequest{DNSNames: []string{"example.com"}} // populate other fields
csr, err := x509.CreateCertificateRequest(rand.Reader, req, priv)
if err != nil {
log.Fatal(err)
}
pub, _, err := client.CreateCert(ctx, csr, 0, true)
if err != nil {
log.Fatal(err)
}
// priv is now the private part of the cert.
// pub is the public part (DER format), including the chain. |
Thanks for the details! Given that DNS validation requires integrating with my DNS provider, I’ll probably use I’m closing this issue as there’s nothing we can do right now about LetsEncrypt/the ACME spec not supporting arbitrary ports, and you’ve referenced the appropriate tracking bugs on their end. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.7.1 linux/amd64
What operating system and processor architecture are you using (
go env
)?What did you do?
https://play.golang.org/p/Nas2lT_XeY
What did you expect to see?
I expected acme/autocert to acquire a certificate and serve my HTTPS request.
What did you see instead?
The program output is:
It might be note-worthy that the hostname in question is reachable via IPv6 only. That’s not a problem for LetsEncrypt, at least not for the well-known URL verification method. I’m not sure whether this is the problem for the particular issue I’m seeing, and I’m also not sure how to further debug this. Any pointers welcome.
The text was updated successfully, but these errors were encountered: