If an absolute domain name (i.e. ends in a '.' like "example.com.") is used
with ssl/tls, the certificate will be reported as invalid. In matchHostnames,
the host and patterns are split on '.' and if the lengths of the resulting
slices do not match, the function returns false. When splitting an absolute
domain name on '.', the slice will have an extra empty string at the end. This
empty string should be discarded before comparison, if present.
Fixes#9828
Change-Id: I0e39674b44a6f93b5024497e76cf1b550832a61d
Reviewed-on: https://go-review.googlesource.com/4380
Reviewed-by: Adam Langley <agl@golang.org>
TryBot: Adam Langley <agl@golang.org>
Additional elements in a DN can be added in via ExtraNames. This
option can also be used for sorting DN elements in a custom order.
Change-Id: Ie408d332de913dc2a33bdd86433be38abb7b55be
Reviewed-on: https://go-review.googlesource.com/2257
Reviewed-by: Adam Langley <agl@golang.org>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Id7857fb9a3b4c957c7050b519552ef1c8e55461e
Reviewed-on: https://go-review.googlesource.com/3126
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
According to RFC5280 the authority key identifier extension MUST included in all
CRLs issued. This patch includes the authority key identifier extension when the
Subject Key Identifier is present in the signing certificate.
RFC5280 states:
"The authority key identifier extension provides a means of identifying the
public key corresponding to the private key used to sign a CRL. The
identification can be based on either the key identifier (the subject key
identifier in the CRL signer's certificate) or the issuer name and serial
number. This extension is especially useful where an issuer has more than one
signing key, either due to multiple concurrent key pairs or due to changeover."
Conforming CRL issuers MUST use the key identifier method, and MUST include this
extension in all CRLs issued."
This CL has been discussed at: http://golang.org/cl/177760043
Change-Id: I9bf50521908bfe777ea2398f154c13e8c90d14ad
Reviewed-on: https://go-review.googlesource.com/2258
Reviewed-by: Adam Langley <agl@golang.org>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Ie4a4a583fb120ff484a5ccf267ecd2a9c5a3902b
Reviewed-on: https://go-review.googlesource.com/2254
Reviewed-by: Adam Langley <agl@golang.org>
Fix SmartOS build that was broken in 682922908f.
SmartOS pretends to be Ubuntu/Debian with respect to its SSL
certificate location.
Change-Id: I5405c6472c8a1e812e472e7301bf6084c17549d6
Reviewed-on: https://go-review.googlesource.com/2704
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC5280 states:
"This optional field describes the version of the encoded CRL. When
extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1)."
This CL has been discussed at: http://golang.org/cl/172560043
Change-Id: I8a72d7593d5ca6714abe9abd6a37437c3b69ab0f
Reviewed-on: https://go-review.googlesource.com/2259
Reviewed-by: Adam Langley <agl@golang.org>
According to RFC4055 a NULL parameter MUST be present in the signature
algorithm. This patch adds the NULL value to the Signature Algorithm
parameters in the signingParamsForPrivateKey function for RSA based keys.
Section 2.1 states:
"There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.
All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.
To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }"
This CL has been discussed at: http://golang.org/cl/177610043
Change-Id: Ic782161938b287f34f64ef5eb1826f0d936f2f71
Reviewed-on: https://go-review.googlesource.com/2256
Reviewed-by: Adam Langley <agl@golang.org>
This CL splits the (ever growing) list of ca cert locations by major unix
platforms (darwin, windows and plan9 are already handled seperately).
Although it is clear the unix variants cannot manage to agree on some standard
locations, we can avoid to some extent an artificial ranking of priority
amongst the supported GOOSs.
* Split certFiles definition by GOOS
* Include NetBSD ca cert location
Fixes#9285
Change-Id: I6df2a3fddf3866e71033e01fce43c31e51b48a9e
Reviewed-on: https://go-review.googlesource.com/2208
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
In [1] the behaviour of encoding/asn1 with respect to marshaling
optional integers was changed. Previously, a zero valued integer would
be omitted when marshaling. After the change, if a default value was
set then the integer would only be omitted if it was the default value.
This changed the behaviour of crypto/x509 because
Certificate.MaxPathLen has a default value of -1 and thus zero valued
MaxPathLens would no longer be omitted when marshaling. This is
arguably a bug-fix -- a value of zero for MaxPathLen is valid and
meaningful and now could be expressed. However it broke users
(including Docker) who were not setting MaxPathLen at all.
This change again causes a zero-valued MaxPathLen to be omitted and
introduces a ZeroMathPathLen member that indicates that, yes, one
really does want a zero. This is ugly, but we value not breaking users.
[1] https://code.google.com/p/go/source/detail?r=4218b3544610e8d9771b89126553177e32687adf
LGTM=rsc
R=rsc
CC=golang-codereviews, golang-dev
https://golang.org/cl/153420045
The ASN.1 encoding of the CRL Distribution Points extension showed an invalid false 'IsCompound' which caused a display problem in the Windows certificate viewer.
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/143320043
On android, root certificates appear to be stored in the folder
/system/etc/security/cacerts, which has many certs in several
different files. This change adds a new array of directories in
which certs can be found.
To test this, I simply tried making a request with the http
library to an HTTPS URL on an android emulator and manually
verified that it worked.
LGTM=crawshaw
R=golang-codereviews, gobot, crawshaw
CC=golang-codereviews
https://golang.org/cl/151800043
