We'll need this for handling name constraints during verification.
Change-Id: I4ef19d9489fb2a9ae9a62699d81cef92a21fda28
Reviewed-on: https://go-review.googlesource.com/62692
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
strings.IndexByte was introduced in go1.2 and it can be used
effectively wherever the second argument to strings.Index is
exactly one byte long.
This avoids generating unnecessary string symbols and saves
a few calls to strings.Index.
Change-Id: I1ab5edb7c4ee9058084cfa57cbcc267c2597e793
Reviewed-on: https://go-review.googlesource.com/65930
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There is already a table of signature algorithm details so the code
should use it for the name too. This avoids mismatches.
Change-Id: I0d4befbae721ec43db9f87cd93173ec12749e4c8
Reviewed-on: https://go-review.googlesource.com/57210
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
signatureAlgorithmDetails already knows the hash function for each
signature algorithm so there's no point in duplicating that. Also, check
that the public key type of the signature algorithm actually matches the
given public key.
Change-Id: I7aab4ea71691fb815d67ba790b721ce02de11b85
Reviewed-on: https://go-review.googlesource.com/57211
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
golang.org/cl/36941 enabled loading of all trusted certs on darwin
for the non-cgo execSecurityRoots.
The corresponding cgo version golang.org/cl/36942 for systemRootsPool
has not been merged yet.
This tests fails reliably on some darwin systems:
--- FAIL: TestSystemRoots (1.28s)
root_darwin_test.go:31: cgo sys roots: 353.552363ms
root_darwin_test.go:32: non-cgo sys roots: 921.85297ms
root_darwin_test.go:44: got 169 roots
root_darwin_test.go:44: got 455 roots
root_darwin_test.go:73: insufficient overlap between cgo and non-cgo roots; want at least 227, have 168
FAIL
FAIL crypto/x509 2.445s
Updates #16532
Updates #21416
Change-Id: I52c2c847651fb3621fdb6ab858ebe8e28894c201
Reviewed-on: https://go-review.googlesource.com/57830
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
asn1.NullRawValue was used according to RFC 3279 2.2.1. Without this tag,
the output didn't match openssl.
Fixes#19972
Change-Id: Ia52ddb810888837f913dbd65c4e1328f6c8084bb
Reviewed-on: https://go-review.googlesource.com/40730
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The current implementation ignores certificates that exist
in the login and System keychains.
This change adds the missing System and login keychain
files to the `/usr/bin/security` command in
`execSecurityRoots`. If the current user cannot be
obtained, the login keychain is ignored.
Refs #16532
Change-Id: I8594a6b8940c58df8a8015b274fa45c39e18862c
Reviewed-on: https://go-review.googlesource.com/36941
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Apply code review suggestion from CL 46715.
The block is doing more than just checking len(r.certs) == len(tc.cns).
It also verifies that certificate common names match.
Change-Id: I28d6926a5da48bd8f6c80aa5e5a1ed6d4990f845
Reviewed-on: https://go-review.googlesource.com/47132
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This panic happens when the test fails due to the returned number of
certificates (r.certs) being less than expected by test case (tc.cns).
When i == len(r.certs) in the for loop, r.certs[i] will cause an index
out of range panic.
Also improve readability, consistency and style of the code. Use the
more common "got x, want y" pattern. See https://golang.org/s/style#useful-test-failures
for reference (and grep codebase for most common occurrences). Add a
comment, and remove blank line separating two blocks that are both
related to verifying that len(r.certs) == len(tc.cns). This should
help with readability.
Remove space after colon in call to t.Fatal, since it adds spaces
between its arguments.
Fixes#20801.
Change-Id: I40476103f1b5a0fa74b05637c250926b571c92fd
Reviewed-on: https://go-review.googlesource.com/46715
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add the ability to override the default file and directory from
which certificates are loaded by setting the OpenSSL compatible
environment variables: SSL_CERT_FILE, SSL_CERT_DIR.
If the variables are set the default locations are not checked.
Added new default file "/usr/local/etc/ssl/cert.pem" for FreeBSD.
Certificates in the first valid location found for both file and
directory are added, instead of only the first file location if
a valid one was found, which is consistent with OpenSSL.
Fixes#3905Fixes#14022Fixes#14311Fixes#16920Fixes#18813 - If user sets SSL_CERT_FILE.
Change-Id: Ia24fb7c1c2ffff4338b4cf214bd040326ce27bb0
Reviewed-on: https://go-review.googlesource.com/36093
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There were a number of places in crypto/x509 that used hardcoded
representations of the ASN.1 NULL type, in both byte slice and
RawValue struct forms. This change adds two new exported vars to
the asn1 package for working with ASN.1 NULL in both its forms, and
converts all usages from the x509 package.
In addition, tests were added to exercise Marshal and Unmarshal on
both vars.
See #19446 for discussion.
Change-Id: I63dbd0835841ccbc810bd6ec794360a84e933f1e
Reviewed-on: https://go-review.googlesource.com/38660
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
For consistency with the other named types in this package, this
change renames the unexported rsaPublicKey struct to pkcs1PublicKey
and positions the declaration up with the other similarly-named
types in pkcs1.go.
See the final comment of #19355 for discussion.
Change-Id: I1fa0366a8efa01602b81bc69287ef747abce84f5
Reviewed-on: https://go-review.googlesource.com/37885
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The code previously tested only whether DNS-name SANs were present in a
certificate which is only approximately correct. In fact, /any/ SAN
extension, including one with no DNS names, should cause the CN to be
ignored.
Change-Id: I3d9824918975be6d4817e7cbb48ed1b0c5a2fc8b
Reviewed-on: https://go-review.googlesource.com/36696
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The AuthorityKeyId value from the template was used by
CreateCertificate, but that wasn't documented. Also, CreateCertificate
would stash a value in the template if it needed to override it, which
was wrong: template should be read-only.
Fixes#18962.
Change-Id: Ida15c54c341e5bbf553756e8aa65021d8085f453
Reviewed-on: https://go-review.googlesource.com/36556
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We added CentOS 7's /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
to the list in response to #17549 - not being able to find any certs otherwise.
Now we have #18813, where CentOS 6 apparently has both that file
and /etc/pki/tls/certs/ca-bundle.crt, and the latter is complete while
the former is not.
Moving the new CentOS 7 file to the bottom of the list should fix both
problems: the CentOS 7 system that didn't have any of the other files
in the list will still find the new one, and existing systems will still
keep using what they were using instead of preferring the new path
that may or may not be complete on some systems.
Fixes#18813.
Change-Id: I5275ab67424b95e7210e14938d3e986c8caee0ba
Reviewed-on: https://go-review.googlesource.com/36429
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
X.509v1 certificates are ancient and should be dead. (They are even
prohibited by the Baseline requirements, section 7.1.1.)
However, there are a number of v1 roots from the 1990's that are still
in operation. Thus crypto/x509.Certificate.CheckSignatureFrom allows
X.509v1 certificates to sign other certificates.
The chain building code, however, only allows v1 certificates to sign
others if they're a root. This change adds a test to check that.
Change-Id: Ib8d81e522f30d41932b89bdf3b19ef3782d8ec12
Reviewed-on: https://go-review.googlesource.com/34383
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also tweak one of the comment lines to fit in 80 characters.
Change-Id: I9c6d2028c29318ba9264486590056cb1ffc8219e
Reviewed-on: https://go-review.googlesource.com/34655
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Piping into security verify-cert only worked on macOS Sierra, and was
flaky for unknown reasons. Users reported that the number of trusted
root certs stopped randomly jumping around once they switched to using
verify-cert against files on disk instead of /dev/stdin.
But even using "security verify-cert" on 150-200 certs took too
long. It took 3.5 seconds on my machine. More than 4 goroutines
hitting verify-cert didn't help much, and soon started to hurt
instead.
New strategy, from comments in the code:
// 1. Run "security trust-settings-export" and "security
// trust-settings-export -d" to discover the set of certs with some
// user-tweaked trusy policy. We're too lazy to parse the XML (at
// least at this stage of Go 1.8) to understand what the trust
// policy actually is. We just learn that there is _some_ policy.
//
// 2. Run "security find-certificate" to dump the list of system root
// CAs in PEM format.
//
// 3. For each dumped cert, conditionally verify it with "security
// verify-cert" if that cert was in the set discovered in Step 1.
// Without the Step 1 optimization, running "security verify-cert"
// 150-200 times takes 3.5 seconds. With the optimization, the
// whole process takes about 180 milliseconds with 1 untrusted root
// CA. (Compared to 110ms in the cgo path)
Fixes#18203
Change-Id: I4e9c11fa50d0273c615382e0d8f9fd03498d4cb4
Reviewed-on: https://go-review.googlesource.com/34389
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
150 is too high for some people.
Reports of 132, 145, 149 on OS X.
Fixes#18203
Change-Id: I559639aba7e87e07d1a1249f8b212b3f34a078ab
Reviewed-on: https://go-review.googlesource.com/34019
Reviewed-by: Russ Cox <rsc@golang.org>
Darwin separately stores bits indicating whether a root certificate
should be trusted; this changes Go to read and use those when
initializing SystemCertPool.
Unfortunately, the trust API is very slow. To avoid a delay of up to
0.5s in initializing the system cert pool, we assume that
the trust settings found in kSecTrustSettingsDomainSystem will always
indicate trust. (That is, all root certs Apple distributes are trusted.)
This is not guaranteed by the API but is true in practice.
In the non-cgo codepath, we do not have that benefit, so we must check
the trust status of every certificate. This causes about 0.5s of delay
in initializing the SystemCertPool.
On OS X 10.11 and older, the "security" command requires a certificate
to be provided in a file and not on stdin, so the non-cgo codepath
creates temporary files for each certificate, further slowing initialization.
Updates #18141.
Change-Id: If681c514047afe5e1a68de6c9d40ceabbce54755
Reviewed-on: https://go-review.googlesource.com/33721
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The tree is inconsistent about single l vs double l in those
words in documentation, test messages, and one error value text.
$ git grep -E '[Mm]arshall(|s|er|ers|ed|ing)' | wc -l
42
$ git grep -E '[Mm]arshal(|s|er|ers|ed|ing)' | wc -l
1694
Make it consistently a single l, per earlier decisions. This means
contributors won't be confused by misleading precedence, and it helps
consistency.
Change the spelling in one error value text in newRawAttributes of
crypto/x509 package to be consistent.
This change was generated with:
perl -i -npe 's,([Mm]arshal)l(|s|er|ers|ed|ing),$1$2,' $(git grep -l -E '[Mm]arshall' | grep -v AUTHORS | grep -v CONTRIBUTORS)
Updates #12431.
Follows https://golang.org/cl/14150.
Change-Id: I85d28a2d7692862ccb02d6a09f5d18538b6049a2
Reviewed-on: https://go-review.googlesource.com/33017
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reportedly, -mmacosx-version-min=10.6 -D__MAC_OS_X_VERSION_MAX_ALLOWED=1060
is problematic.
It means min 10.6 and max 10.6, thus exactly 10.6. But we only support
10.8+.
It never caused us problems, because we build on Macs, but apparently
if you cross-compile from Linux with some Mac compiler SDK thing, then
things break?
This was added in https://golang.org/cl/5700083 for #3131, and the
intent at the time was to pin to exactly 10.6. So it wasn't a mistake,
but it is definitely outdated.
Given that we now support 10.8 as the min, update it to 1080.
Fixes#17732
Change-Id: I6cc8ab6ac62b8638a5025952b830f23e8822b2a6
Reviewed-on: https://go-review.googlesource.com/32580
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Since a root certificate is self-signed, it's a valid child of itself.
If a root certificate appeared both in the pool of intermediates and
roots the verification code could find a chain which included it twice:
first as an intermediate and then as a root. (Existing checks prevented
the code from looping any more.)
This change stops the exact same certificate from appearing twice in a
chain. This simplifies the results in the face of the common
configuration error of a TLS server returning a root certificate.
(This should also stop two different versions of the “same” root
appearing in a chain because the self-signature on one will not validate
for the other.)
Fixes#16800.
Change-Id: I004853baa0eea27b44d47b9b34f96113a92ebac8
Reviewed-on: https://go-review.googlesource.com/32121
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
By using these utility functions, the code can be made a little shorter.
Thanks to Omar Shafie for pointing this out in
https://golang.org/cl/27393/.
Change-Id: I33fd97cf7d60a31d0844ec16c12bba530dcc6f6d
Reviewed-on: https://go-review.googlesource.com/32120
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The Subject and Issuer names in a certificate look like they should be a
list of key-value pairs. However, they're actually a list of lists of
key-value pairs. Previously we only looked at the first element of each
sublist and the vast majority of certificates only have one element per
sublist.
However, it's possible to have multiple elements and some 360
certificates from the “Pilot” log are so constructed.
This change causes all elements of the sublists to be processed.
Fixes#16836.
Change-Id: Ie0a5159135b08226ec517fcf251aa17aada37857
Reviewed-on: https://go-review.googlesource.com/30810
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RHEL 7 introduces a new tool, update-ca-trust(8), which places the
certificate bundle in a new location. Add this path to the list of
locations that are searched for the certificate bundle.
Fixes#15749
Change-Id: Idc97f885ee48ef085f1eb4dacbd1c2cf55f94ff5
Reviewed-on: https://go-review.googlesource.com/30375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, if a certificate contains no names (that we parsed),
verification will return the confusing error:
x509: certificate is valid for , not example.com.
This change improves the error for that situation.
Fixes#16834.
Change-Id: I2ed9ed08298d7d50df758e503bdb55277449bf55
Reviewed-on: https://go-review.googlesource.com/30152
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix bug in UnknownAuthorityError.Error that would never allow Org
Name to be inserted into error message if the Common Name was empty.
Create tests for all three paths in UnknownAuthorityError.Error
Change-Id: Id8afc444e897ef549df682d93a8563fd9de22a2b
Reviewed-on: https://go-review.googlesource.com/27992
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change makes sure that tests are run with the correct
version of the go tool. The correct version is the one that
we invoked with "go test", not the one that is first in our path.
Fixes#16577
Change-Id: If22c8f8c3ec9e7c35d094362873819f2fbb8559b
Reviewed-on: https://go-review.googlesource.com/28089
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In other systems, putting a leaf certificate in the root store works to
express that exactly that certificate is acceptable. This change makes
that work in Go too.
Fixes#16763.
Change-Id: I5c0a8dbc47aa631b23dd49061fb217ed8b0c719c
Reviewed-on: https://go-review.googlesource.com/27393
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For some reason, ISO decided to duplicate the OID for RSA+SHA1. Most
pertinantly, the makecert.exe utility on Windows is known to have used
this OID.
This change makes the ISO OID an alias for the normal one.
Change-Id: I60b76265bf1721282bdb0d5c99c98d227c18a878
Reviewed-on: https://go-review.googlesource.com/27394
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Although the term “RSA” is almost synonymous with PKCS#1 v1.5, that
standard is quite flawed, cryptographically speaking. Bellare and
Rogaway fixed PKCS#1 v1.5 with OAEP (for encryption) and PSS (for
signatures) but they only see a fraction of the use of v1.5.
This change adds support for creating and verifying X.509 certificates
that use PSS signatures. Sadly, every possible dimension of flexibility
seems to have been reflected in the integration of X.509 and PSS
resulting in a huge amount of excess complexity. This change only
supports one “sane” configuration for each of SHA-{256, 384, 512}.
Hopefully this is sufficient because it saves a lot of complexity in the
code.
Although X.509 certificates with PSS signatures are rare, I'm inclined
to look favourably on them because they are sufficiently superior.
Fixes#15958.
Change-Id: I7282e0b68ad0177209f8b2add473b94aa5224c07
Reviewed-on: https://go-review.googlesource.com/24743
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The RFC is clear that the Parameters in an AlgorithmIdentifer for an RSA
public key must be NULL. BoringSSL enforces this so we have strong
evidence that this is a widely compatible change.
Embarrassingly enough, the major source of violations of this is us. Go
used to get this correct in only one of two places. This was only fixed
in 2013 (with 4874bc9b). That's why lots of test certificates are
updated in this change.
Fixes#16166.
Change-Id: Ib9a4551349354c66e730d44eb8cee4ec402ea8ab
Reviewed-on: https://go-review.googlesource.com/27312
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>