Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2B99E200CDE for ; Tue, 8 Aug 2017 13:22:48 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2A09016716A; Tue, 8 Aug 2017 11:22:48 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 942C5167167 for ; Tue, 8 Aug 2017 13:22:47 +0200 (CEST) Received: (qmail 26792 invoked by uid 500); 8 Aug 2017 11:22:46 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 26782 invoked by uid 99); 8 Aug 2017 11:22:46 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Aug 2017 11:22:46 +0000 Received: from [192.168.23.12] (host217-44-155-55.range217-44.btcentralplus.com [217.44.155.55]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 576BD1A0048 for ; Tue, 8 Aug 2017 11:22:44 +0000 (UTC) To: Tomcat Developers List From: Mark Thomas Subject: Test keys and certs Message-ID: <26897d05-0174-0dd1-e6f5-79b38aa9ebcc@apache.org> Date: Tue, 8 Aug 2017 12:22:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit archived-at: Tue, 08 Aug 2017 11:22:48 -0000 All, Just a heads up. A few days ago I started to look at bug 59423. I saw all sorts of errors when I tried to configure a clean Tomcat build for CLIENT-CERT. As I dug into the errors it appeared that Tomcat wasn't handling an unexpected connection close during the renegotiation. I have a patch for this that I'll commit once I have completed some more testing. I also spent a long time trying to figure out why CLIENT-CERT was failing unexpectedly in some cases. The short answer is that it fails in Chrome but not with FireFox nor with openssl s_client. The failure in Chrome occurs when it tries to find a matching user cert for the provided trusted certs. For some reason Chrome can't match our current user test cert with the CA. My guess is that expects/requires more fields to be populated than just C and CN. I've been experimenting with a new CA created from scratch that populates more of the fields and this does work with Chrome. Therefore, I plan to replace our current test CA with the new one I have created and, therefore, also replace all the test keys and certs used in the unit tests. I'll also update the notes for creating these files and the openssl.cnf with a few more defaults. I might even get around to looking at 59423 ;) Mark [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=59423 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org