Client certificates in HTTP/2

Yoav Nir <> Tue, 09 June 2015 08:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BFE0B1B2A45 for <>; Tue, 9 Jun 2015 01:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XDHU9CIo9W5U for <>; Tue, 9 Jun 2015 01:03:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 539001B2A43 for <>; Tue, 9 Jun 2015 01:03:46 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Z2EQn-00073v-DF for; Tue, 09 Jun 2015 07:58:45 +0000
Resent-Date: Tue, 09 Jun 2015 07:58:45 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Z2EQe-000710-JG for; Tue, 09 Jun 2015 07:58:36 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Z2EQY-0005ng-Sc for; Tue, 09 Jun 2015 07:58:34 +0000
Received: by wifx6 with SMTP id x6so7391746wif.0 for <>; Tue, 09 Jun 2015 00:58:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=e+1VUlx9+huCDYbSfcf3ffrkoIrLBLsmEpQ9ATJFAnI=; b=z671X6F71tyEkjPUuwyoJMUNBVEKwJvjd86ME3DwXshuKf/R2Qlw/Klo0tuf/DQWS0 tDEc+qhL31Cc9b3E1HbALI+wgNkwCPIzTwcu1poeDYWz1Al1U8VvB3I4PnfLWviV8hW5 F0gqEp+OFt8fYfwGBiMTEdhyXD0JwBMxklbUSqar3apy2sGit84jrS5iL4bekSkzRiku /2JNta0h+yx9zv7FilpJhPBXY7KQ5LHze7GLpXwhy48BU2WBh+fp4MlXpsgZYHEj+O8F I7fmB9bUeVqtZr2VFan9QuL4QQ5WNhUV/C5sWHq5izHH17SwHuAMGNZMNKv3XhwbS9XN F5Pw==
X-Received: by with SMTP id w18mr29472136wiv.77.1433836684513; Tue, 09 Jun 2015 00:58:04 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ha4sm1483955wib.0.2015. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jun 2015 00:58:03 -0700 (PDT)
From: Yoav Nir <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
Date: Tue, 09 Jun 2015 10:58:00 +0300
To: HTTP Working Group <>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-0.732, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1Z2EQY-0005ng-Sc 4af183278f568c6695301753f554eeba
Subject: Client certificates in HTTP/2
Archived-At: <>
X-Mailing-List: <> archive/latest/29712
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


Long time ago there was a long discussion about using client certificates on the web with HTTP/2. Feel free to skip the next paragraph if you remember the issue.

Most of the web does not use client certificates. Websites that do don’t like users to get a certificate picker when they first land on the page. So what they do is protect the site with regular, server-authenticated TLS and have a landing page. On the landing page there’s going to be something clickable that says “login with certificates”. When the user clicks that, it sends a request for some resource (maybe “/loginWithCerts.html”). When the server gets that request, it triggers the TLS layer to re-negotiate, this time with the certificate request message that causes the certificate picker to pop up. This is the way it’s usually done in HTTP/1, but for HTTP/2, section 9.2.1 prohibits this use or renegotiation and hints at future specification that might provide this.

So a year ago Martin Thomson wrote a pair of draft for solving this: one an HTTP authentication scheme that just says, “go away and come back with a certificate”, while the other is a TLS extension that tells the server that the client would like to authenticate:

Neither was adopted, here or at TLS, so currently HTTP/2 is not usable with mutual authentication. Why has this (useful IMO) extension withered on the vine rather than progressed?  If anyone needs help in pushing this along, I’ll be glad to help.