Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

Tony Arcieri <> Mon, 16 April 2018 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F28A8126B6E for <>; Mon, 16 Apr 2018 07:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ax9vLhId0CBf for <>; Mon, 16 Apr 2018 07:54:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBC60124319 for <>; Mon, 16 Apr 2018 07:54:17 -0700 (PDT)
Received: by with SMTP id i75so4837105vke.8 for <>; Mon, 16 Apr 2018 07:54:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fq3FKhYfR0uQvVJe1JWJk/87hpoOAmeXE0cVIXPcKlE=; b=NgMUkG1Yx1al0s7eKBP8HfaiucwMw3ZBYKsNRIhbrbRQ04aMcxdH0Qm/iV2cOcvw8d OdGydDpCjouDgsYSea3DOc+m5JSLU8tJc/Z3TYRudYLAlnmvs0JtvK3a7BySmLkEZ8Zd gbHT4IObjGKJzVAhpKejD4D6zWsGjuhGVN3t/oRVQaCnUoskgXljvLyEmLOobDzp5L1+ bOF4ZLeBhd7xYRXQNYlAPrOmE3e9JwW2rtCEIiwKJsiEg3MCPjGPjxLgbddHwDQGawam WD0NwSDuWP4I506frmQll0mM6y8svKARxNeLvQ//KoVrW+0iI6758aMH7Srl+shVqPQ9 PHXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fq3FKhYfR0uQvVJe1JWJk/87hpoOAmeXE0cVIXPcKlE=; b=P4N6VUdb6tYBF7iNNq/lSTbXsQSLtfitBNJyObf5H1loUnPEFlvxkxKucpbS8XLmzv F0JUKEp9t0ak8YP0yH2+qCSzzbggUafqGamFhcV5G0FstwxXrVjMy4s3JYDKpGMzQxyd LqR7CcASnpTmh0R/eOJimlNmm6hyEO+v46MbGRBk9goRVpmPliAijmGStiEGFeezxfeU G863lbNa9FkfyB1j6+q8zuRhUwnxO75IG0Qwlt9p3lqsWj65BqkTd3462+iYwFJsjZSB k324jHPMKuO/id4s5oBJ9ohUA0aejjpCWxsSUAZfzP7AVPOZpaxDY9EguVVZFAVZhiw0 VQdg==
X-Gm-Message-State: ALQs6tDrrn+a8s/4oYj1KtHeJIq5T11qgiVThXLViWN7/vLX6hEl5ljo 20WlFB3bRb+/882MRMVClE3+9LsxdxW8tMrxvWRPr8yU
X-Google-Smtp-Source: AIpwx4+d0eyZxI3AHN9YAdnyUu/kkRoqxRaEKWh9Jyxk/Upo3YoeMBijO5RAvuCrdINJKbVTeFuW/Cff0bD9SUdtBpE=
X-Received: by with SMTP id q184mr11131217vkf.114.1523890456706; Mon, 16 Apr 2018 07:54:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Apr 2018 07:53:56 -0700 (PDT)
In-Reply-To: <064a01d3d569$2a3cdaf0$7eb690d0$>
References: <064a01d3d569$2a3cdaf0$7eb690d0$>
From: Tony Arcieri <>
Date: Mon, 16 Apr 2018 07:53:56 -0700
Message-ID: <>
To: Tobias Gondrom <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="001a1143750059452f0569f8654b"
Archived-At: <>
Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Apr 2018 14:54:20 -0000

On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <>

> Are there any RFCs that speak (beyond the general verification of the
> certificate in mutual TLS authentication) to the need to also verify the CN
> inside the client certificate against an additional whitelist _*before*_
> establishing a TLS connection.

I'm not sure what you mean by "before establishing a TLS connection", as
certificates are generally exchanged during the TLS handshake, so doing
anything "before establishing a TLS connection" would require the server
somehow know the client's certificate a priori. There are several systems
that will abort the handshake unless they receive an acceptable client
certificate, however.

I don't know of any RFCs for this per se, or anything that uses the Subject
CN (I think almost everything has completely moved away from using the CN).
However, as an example, SPIFFE is a largely Kubernetes-focused identity
system which encodes a "SPIFFE ID" in the client cert's subjectAltName and
uses that to determine whether clients are authorized to continue a TLS

Tony Arcieri