This exports the system cert pool.
The system cert loading was refactored to let it be run multiple times
(so callers get a copy, and can't mutate global state), and also to
not discard errors.
SystemCertPool returns an error on Windows. Maybe it's fixable later,
but so far we haven't used it, since the system verifies TLS.
Fixes#13335
Change-Id: I3dfb4656a373f241bae8529076d24c5f532f113c
Reviewed-on: https://go-review.googlesource.com/21293
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
PKIX versions are off-by-one, so v1 is actually a zero on the wire, v2
is a one, and so on.
The RFC says that the version in a CRL is optional, but doesn't say what
the default is. Since v2 is the only accepted version, I had made the
default v2. However, OpenSSL considers the default to be v1. Also, if
the default is v2 and the element is optional then we'll never actually
write v2 on the wire. That's contrary to the RFC which clearly assumes
that v2 will be expressed on the wire in some cases.
Therefore, this change aligns with OpenSSL and assumes that v1 is the
default CRL version.
Fixes#13931
[1] https://tools.ietf.org/html/rfc5280#section-5.1
Change-Id: Ic0f638ebdd21981d92a99a882affebf3a77ab71a
Reviewed-on: https://go-review.googlesource.com/20544
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The default version of an X.509 certificate is v1, which is encoded on
the wire as a zero.
Fixes#13382.
Change-Id: I5fd725c3fc8b08fd978ab694a3e2d6d2a495918b
Reviewed-on: https://go-review.googlesource.com/20548
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Named returned values should only be used on public funcs and methods
when it contributes to the documentation.
Named return values should not be used if they're only saving the
programmer a few lines of code inside the body of the function,
especially if that means there's stutter in the documentation or it
was only there so the programmer could use a naked return
statement. (Naked returns should not be used except in very small
functions)
This change is a manual audit & cleanup of public func signatures.
Signatures were not changed if:
* the func was private (wouldn't be in public godoc)
* the documentation referenced it
* the named return value was an interesting name. (i.e. it wasn't
simply stutter, repeating the name of the type)
There should be no changes in behavior. (At least: none intended)
Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109
Reviewed-on: https://go-review.googlesource.com/20024
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The existing documentation for ParsePKIXPublicKey is difficult to understand
and the return type of the parsed public key are not mentioned explicitly.
Descriptions about types of public key supported, as well as an example on
how to use type assertions to determine return type of a parsed public key
has been added.
Fixes#14355
Change-Id: Ib9561efb34255292735742c0b3e835c4b97ac589
Reviewed-on: https://go-review.googlesource.com/19757
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
SEC-1 says: “The component privateKey is the private key defined to be
the octet string of length ⌊log₂(n)/8⌋ (where n is the order of the
curve)”.
Previously the code for parsing ECC private keys would panic (on
non-amd64) when the private was too long. It would also pass a too-short
private key to crypto/elliptic, possibly resulting in undesirable
behaviour.
This change makes the parsing function handle both too much and too
little padding because GnuTLS does the former and OpenSSL did the latter
until 30cd4ff294252c4b6a4b69cbef6a5b4117705d22. It also causes
serialisation to pad private keys correctly.
Fixes#13699
Change-Id: If9c2faeaeb45af8a4d7770d784f3d2633e7f8290
Reviewed-on: https://go-review.googlesource.com/18094
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Until now we've used ErrUnknownAlgorithm but that's a bit confusing
when it is returned for obviously-known things like MD5.
Fixes#10431.
Change-Id: Ief8a8ef46e5b99bd4fd18e1acd7ae398a484bac3
Reviewed-on: https://go-review.googlesource.com/17380
Reviewed-by: Adam Langley <agl@golang.org>
Some software that produces certificates doesn't encode integers
correctly and, about half the time, ends up producing certificates with
serial numbers that are actually negative.
This buggy software, sadly, appears to be common enough that we should
let these errors pass. This change allows a Certificate.SerialNumber to
be negative.
Fixes#8265.
Change-Id: Ief35dae23988fb6d5e2873e3c521366fb03c6af4
Reviewed-on: https://go-review.googlesource.com/17247
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The format for a CSR is horribly underspecified and we had a mistake.
The code was parsing the attributes from the CSR as a
pkix.AttributeTypeAndValueSET, which is only almost correct: it works so
long as the requested extensions don't contain the optional “critical”
flag.
Unfortunately this mistake is exported somewhat in the API and the
Attributes field of a CSR actually has the wrong type. I've moved this
field to the bottom of the structure and updated the comment to reflect
this.
The Extensions and other fields of the CSR structure can be saved
however and this change does that.
Fixes#11897.
Change-Id: If8e2f5c21934800b72b041e38691efc3e897ecf1
Reviewed-on: https://go-review.googlesource.com/12717
Reviewed-by: Rob Pike <r@golang.org>
Platform-specific verification needs the ASN.1 contents of a certificate
but that might not be provided if the Certificate was not created by
ParseCertificate. In order to avoid a panic on Windows, and to make
behaviour consistent across platforms, this change causes verification
to fail when the ASN.1 contents of a certificate are not available.
Fixes#12184
Change-Id: I4395d74934e675c179eaf4cded1094a756e478bb
Reviewed-on: https://go-review.googlesource.com/14053
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This allows running a cross-compile like
GOOS=darwin GOARCH=arm go build std
to check that everything builds.
Otherwise there is a redefinition error because both
root_nocgo_darwin.go and root_darwin_armx.go
supply initSystemRoots.
Change-Id: Ic95976b2b698d28c629bfc93d8dac0048b023578
Reviewed-on: https://go-review.googlesource.com/12897
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The iOS simulator compiles with GOOS=darwin GOARCH=386, and x509
sets the inappropriate flag -mmacosx-version-min=10.6. Condition
its compilation on the absence of an "ios" build tag.
Fixes#11736.
Change-Id: I4aa230643347320c3cb9d03b972734b2e0db930e
Reviewed-on: https://go-review.googlesource.com/12301
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change 7c7126cfeb removed the primality
checking in Validate to save CPU time. That check happened to be
filtering out private keys with primes that were zero or one. Without
that filtering, such primes cause a panic when trying to use such a
private key.
This change specifically checks for and rejects primes ≤ 1 in Validate.
Fixes#11233.
Change-Id: Ie6537edb8250c07a45aaf50dab43227002ee7386
Reviewed-on: https://go-review.googlesource.com/11611
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If an encrypted PEM block contained ciphertext that was not a multiple
of the block size then the code would panic. This change tests for that
case and returns an error.
Fixes#11215.
Change-Id: I7b700f99e20810c4f545519b1e9d766b4640e8a7
Reviewed-on: https://go-review.googlesource.com/11097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The X.509 parser was allowing trailing data after a number of structures
in certificates and public keys. There's no obvious security issue here,
esp in certificates which are signed anyway, but this change makes
trailing data an error just in case.
Fixes#10583
Change-Id: Idc289914899600697fc6d30482227ff4bf479241
Reviewed-on: https://go-review.googlesource.com/9473
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Previously, unknown critical extensions were a parse error. However, for
some cases one wishes to parse and use a certificate that may contain
these extensions. For example, when using a certificate in a TLS server:
it's the client's concern whether it understands the critical extensions
but the server still wishes to parse SNI values out of the certificate
etc.
This change moves the rejection of unknown critical extensions from
ParseCertificate to Certificate.Verify. The former will now record the
OIDs of unknown critical extensions in the Certificate and the latter
will fail to verify certificates with them. If a user of this package
wishes to handle any unknown critical extensions themselves, they can
extract the extensions from Certificate.Extensions, process them and
remove known OIDs from Certificate.UnknownCriticalExtensions.
See discussion at
https://groups.google.com/forum/#!msg/golang-nuts/IrzoZlwalTQ/qdK1k-ogeHIJ
and in the linked bug.
Fixes#10459
Change-Id: I762521a44c01160fa0901f990ba2f5d4977d7977
Reviewed-on: https://go-review.googlesource.com/9390
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This implements a method for x509.CertificateRequest to prevent
certain attacks and to allow a CA/RA to properly check the validity
of the binding between an end entity and a key pair, to prove that
it has possession of (i.e., is able to use) the private key
corresponding to the public key for which a certificate is requested.
RFC 2986 section 3 states:
"A certification authority fulfills the request by authenticating the
requesting entity and verifying the entity's signature, and, if the
request is valid, constructing an X.509 certificate from the
distinguished name and public key, the issuer name, and the
certification authority's choice of serial number, validity period,
and signature algorithm."
Change-Id: I37795c3b1dfdfdd455d870e499b63885eb9bda4f
Reviewed-on: https://go-review.googlesource.com/7371
Reviewed-by: Adam Langley <agl@golang.org>
Just like darwin/arm.
Change-Id: Ib0438021bfe9eb105222b93e5bb375c282cc7b8c
Reviewed-on: https://go-review.googlesource.com/8822
Reviewed-by: Minux Ma <minux@golang.org>
A CSR containing challengePassword or unstructuredName Attributes
(included in default OpenSSL prompts) would break ASN.1 parsing.
This updates the parsing structures to allow but then ignore these
fields.
See this CFSSL issue: https://github.com/cloudflare/cfssl/issues/115
Change-Id: I26a3bf1794589d27e6e763da88ae32276f0170c7
Reviewed-on: https://go-review.googlesource.com/8160
Reviewed-by: Adam Langley <agl@golang.org>
cl8167 introduced internal/syscall/windows.GetVersion, but we already
have that function in syscall.GetVersion. Use that instead.
Also revert all internal/syscall/windows cl8167 changes.
Change-Id: I512a5bf4b3b696e93aaf69e9e8b7df7022670ec0
Reviewed-on: https://go-review.googlesource.com/8302
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
Windows XP SP2 and Windows 2003 do not support SHA2.
Change-Id: Ica5faed040e9ced8b79fe78d512586e0e8788b3f
Reviewed-on: https://go-review.googlesource.com/8167
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: I8b18dc840425b72d7172a35cb0ba004bd156492d
Reviewed-on: https://go-review.googlesource.com/6252
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Previously, we didn't handle absolute DNS names in certificates the same
way as Chromium, and we probably shouldn't diverge from major browsers.
Change-Id: I56a3962ad1002f68b5dbd65ae90991b82c2f5629
Reviewed-on: https://go-review.googlesource.com/5692
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC 6125 now specifies that wildcards are only allowed for the leftmost
label in a pattern: https://tools.ietf.org/html/rfc6125#section-6.4.3.
This change updates Go to match the behaviour of major browsers in this
respect.
Fixes#9834.
Change-Id: I37c10a35177133624568f2e0cf2767533926b04a
Reviewed-on: https://go-review.googlesource.com/5691
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There was a missing continue that caused certificates with critical
certificate-policy extensions to be rejected. Additionally, that code
structure in general was prone to exactly that bug so I changed it
around to hopefully be more robust in the future.
Fixes#9964.
Change-Id: I58fc6ef3a84c1bd292a35b8b700f44ef312ec1c1
Reviewed-on: https://go-review.googlesource.com/5670
Reviewed-by: Andrew Gerrand <adg@golang.org>