From 65c5bd0dd62ec361f6555673c62f6f4f6dbadec9 Mon Sep 17 00:00:00 2001 From: Adam Langley Date: Mon, 8 Jun 2015 14:24:18 -0700 Subject: [PATCH] crypto/tls: don't require an explicit client-auth EKU. Previously we enforced both that the extended key usages of a client certificate chain allowed for client authentication, and that the client-auth EKU was in the leaf certificate. This change removes the latter requirement. It's still the case that the chain must be compatible with the client-auth EKU (i.e. that a parent certificate isn't limited to another usage, like S/MIME), but we'll now accept a leaf certificate with no EKUs for client-auth. While it would be nice if all client certificates were explicit in their intended purpose, I no longer feel that this battle is worthwhile. Fixes #11087. Change-Id: I777e695101cbeba069b730163533e2977f4dc1fc Reviewed-on: https://go-review.googlesource.com/10806 Reviewed-by: Andrew Gerrand Run-TryBot: Adam Langley --- handshake_server.go | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/handshake_server.go b/handshake_server.go index accfa6f..e16cddc 100644 --- a/handshake_server.go +++ b/handshake_server.go @@ -687,18 +687,6 @@ func (hs *serverHandshakeState) processCertsFromClient(certificates [][]byte) (c return nil, errors.New("tls: failed to verify client's certificate: " + err.Error()) } - ok := false - for _, ku := range certs[0].ExtKeyUsage { - if ku == x509.ExtKeyUsageClientAuth { - ok = true - break - } - } - if !ok { - c.sendAlert(alertHandshakeFailure) - return nil, errors.New("tls: client's certificate's extended key usage doesn't permit it to be used for client authentication") - } - c.verifiedChains = chains }