crypto/go.sum

9 строки
784 B
Plaintext
Исходник Обычный вид История

acme/autocert: make host of TLS certificate to be obtained always Punycode According to the [RFC 5280, section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6): > ... > When the subjectAltName extension contains a domain name system > label, the domain name MUST be stored in the dNSName (an IA5String). > The name MUST be in the "preferred name syntax", as specified by > Section 3.5 of [RFC1034] and as modified by Section 2.1 of > [RFC1123]. Note that while uppercase and lowercase letters are > allowed in domain names, no significance is attached to the case. > ... And the [RFC 1034, section 3.5](https://tools.ietf.org/html/rfc1034#section-3.5): > ... > Note that while upper and lower case letters are allowed in domain > names, no significance is attached to the case. That is, two names with > the same spelling but different case are to be treated as if identical. > ... We should return the same TLS certificate for both `example.com` and `EXAMPLE.COM`. But the `autocert.Manager.GetCertificate` treats the two as totally different, it signs and returns two different TLS certificates. Moreover, now the `autocert.Manager.GetCertificate` and the `autocert.HostWhitelist` can only handle Punycode IDN. If the client sends a Unicode IDN to `autocert.Manager.GetCertificate` (cURL is doing this), the "Invalid character in DNS name" error will be triggered. This PR corrects these problems by converting the host of the TLS certificate to be obtained to Punycode via `idna.Lookup.ToASCII`. Change-Id: I993821b3a6ae532a53772e2db00524479ef111af GitHub-Last-Rev: 6c12694574b6ac71a920da8a8bdb130c0b6e0272 GitHub-Pull-Request: golang/crypto#85 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/171997 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 20:01:29 +03:00
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3 h1:0GoQqolDA55aaLxZyTzK/Y2ePZzZTUrRacwib7cNsYQ=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190412213103-97732733099d h1:+R4KGOnez64A81RvjARKc4UT5/tI9ujCIVX+P5KiHuI=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
acme/autocert: make host of TLS certificate to be obtained always Punycode According to the [RFC 5280, section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6): > ... > When the subjectAltName extension contains a domain name system > label, the domain name MUST be stored in the dNSName (an IA5String). > The name MUST be in the "preferred name syntax", as specified by > Section 3.5 of [RFC1034] and as modified by Section 2.1 of > [RFC1123]. Note that while uppercase and lowercase letters are > allowed in domain names, no significance is attached to the case. > ... And the [RFC 1034, section 3.5](https://tools.ietf.org/html/rfc1034#section-3.5): > ... > Note that while upper and lower case letters are allowed in domain > names, no significance is attached to the case. That is, two names with > the same spelling but different case are to be treated as if identical. > ... We should return the same TLS certificate for both `example.com` and `EXAMPLE.COM`. But the `autocert.Manager.GetCertificate` treats the two as totally different, it signs and returns two different TLS certificates. Moreover, now the `autocert.Manager.GetCertificate` and the `autocert.HostWhitelist` can only handle Punycode IDN. If the client sends a Unicode IDN to `autocert.Manager.GetCertificate` (cURL is doing this), the "Invalid character in DNS name" error will be triggered. This PR corrects these problems by converting the host of the TLS certificate to be obtained to Punycode via `idna.Lookup.ToASCII`. Change-Id: I993821b3a6ae532a53772e2db00524479ef111af GitHub-Last-Rev: 6c12694574b6ac71a920da8a8bdb130c0b6e0272 GitHub-Pull-Request: golang/crypto#85 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/171997 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-22 20:01:29 +03:00
golang.org/x/text v0.3.0 h1:g61tztE5qeGQ89tm6NTjjM9VPIm088od1l6aSorWRWg=
golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=