On Windows, CryptoAPI is finding an alternative validation path. Since
this is a little non-deterministic, this change disables that test
when using system validation.
R=golang-dev
CC=golang-dev
https://golang.org/cl/7313068
By default, crypto/x509 assumes that users wish to validate
certificates for ServerAuth. However, due to historical reasons,
COMODO's intermediates don't specify ServerAuth as an allowed key
usage.
Rather NSS and CryptoAPI both allow these SGC OIDs to be equivalent to
ServerAuth.
R=rsc
CC=golang-dev
https://golang.org/cl/7312070
On Windows, crypto/x509 passes through to Windows's CryptoAPI
to verify certificate chains. This method can't produce a
SystemRootsError, so make sure we always skip the test on
Windows.
This is needed because testVerify is called in both
TestGoVerify and TestSystemVerify on Windows - one is for
testing the Go verifier, the other one is for testing the
CryptoAPI verifier. The orignal CL tried to sidestep
this issue by setting systemSkip to true, but that only
affected TestSystemVerify.
R=golang-dev, agl, snaury, minux.ma
CC=golang-dev
https://golang.org/cl/7185043
Flame motivated me to get around to adding extended key usage support
so that code signing certificates can't be used for TLS server
authentication and vice versa.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6304065
This moves the various CA root fetchers from crypto/tls into crypto/x509.
The move was brought about by issue 2997. Windows doesn't ship with all
its root certificates, but will instead download them as-needed when using
CryptoAPI for certificate verification.
This CL changes crypto/x509 to verify a certificate using the system root
CAs when VerifyOptions.RootCAs == nil. On Windows, this verification is
now implemented using Windows's CryptoAPI. All other root fetchers are
unchanged, and still use Go's own verification code.
The CL also fixes the hostname matching logic in crypto/tls/tls.go, in
order to be able to test whether hostname mismatches are honored by the
Windows verification code.
The move to crypto/x509 also allows other packages to use the OS-provided
root certificates, instead of hiding them inside the crypto/tls package.
Fixes#2997.
R=agl, golang-dev, alex.brainman, rsc, mikkel
CC=golang-dev
https://golang.org/cl/5700087
X509 names, like everything else X509, are ludicrously general. This
change keeps the raw version of the subject and issuer around for
matching. Since certificates use a distinguished encoding, comparing
the encoding is the same as comparing the values directly. This came
up recently when parsing the NSS built-in certificates which use the
raw subject and issuer for matching trust records to certificates.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5275047
It's possible to include a self-signed root certificate as an
intermediate and push Verify into a loop.
I already had a test for this so I thought that it was ok, but it
turns out that the test was void because the Verisign root certificate
doesn't contain the "IsCA" flag and so it wasn't an acceptable
intermediate certificate for that reason.
R=bradfitz
CC=golang-dev
https://golang.org/cl/4657080
This is a core API change.
1) gofix misc src
2) Manual adjustments to the following files under src/pkg:
gob/decode.go
rpc/client.go
os/error.go
io/io.go
bufio/bufio.go
http/request.go
websocket/client.go
as well as:
src/cmd/gofix/testdata/*.go.in (reverted)
test/fixedbugs/bug243.go
3) Implemented gofix patch (oserrorstring.go) and test case (oserrorstring_test.go)
Compiles and runs all tests.
R=r, rsc, gri
CC=golang-dev
https://golang.org/cl/4607052
I ran the new verification code against a large number of certificates
with a huge (>1000) number of intermediates.
I had previously convinced myself that a cycle in the certificate
graph implied a cycle in the hash graph (and thus, a contradiction).
This is bogus because the signatures don't cover each other.
Secondly, I managed to drive the verification into a time explosion
with a fully connected graph of certificates. The code would try to
walk the factorial number of paths.
This change switches the CertPool to dealing with indexes of
certificates rather than pointers: this makes equality easy. (I didn't
want to compare pointers because a reasonable gc could move objects
around over time.)
Secondly, verification now memorizes the chains from a given
certificate. This is dynamic programming for the lazy, but there's a
solid reason behind it: dynamic programming would ignore the Issuer
hints that we can exploit by walking up the chain rather than down.
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4439070
People have a need to verify certificates in situations other than TLS
client handshaking. Thus this CL moves certificate verification into
x509 and expands its abilities.
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4407046
