Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebJs5-000409-CD for pgsql-docs@arkaria.postgresql.org; Tue, 16 Jan 2018 05:33:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebJs4-0001IE-NQ for pgsql-docs@arkaria.postgresql.org; Tue, 16 Jan 2018 05:33:16 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ebJs4-0001I4-CK for pgsql-docs@lists.postgresql.org; Tue, 16 Jan 2018 05:33:16 +0000 Received: from mail-pl0-x242.google.com ([2607:f8b0:400e:c01::242]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ebJs1-0007eJ-Ei for pgsql-docs@postgresql.org; Tue, 16 Jan 2018 05:33:14 +0000 Received: by mail-pl0-x242.google.com with SMTP id 62so5307741pld.7 for ; Mon, 15 Jan 2018 21:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hPK280KYFXXf1ycxvPvaaysHZWTUW7UXMCOApJaUOWU=; b=vb8lVLQ6Uj5VZXQuLBLm23ctVwfmO7teZIEqQnU8805f5YNKcMBxOzPz/TigtE8CTu s/9a5cSK941ECefAXOxDCbZKKbwG766r9SH1SVFeqZUV6N87mtpNO/BB+xhGnfkQbz29 skst5GjOCYPeVt+QM+DqyxcGa/YUGFb+trDxNwnnd7mQeZU43sxHsdyenKuBK7U9wWbP KxhaP5QH90FSTW3IPqMUeBhfObLe4AKeJuWaRJNGEZj+XMuMonFSjdT2aBGxEsXaFKBh nKBPaxxJmOIqLBEaZ96yR9zdOi79y8lM94WbxpDGP0GbxvBjYrDtmFlBwS9f4M1s9c7j XoVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hPK280KYFXXf1ycxvPvaaysHZWTUW7UXMCOApJaUOWU=; b=Hz+gbJ18ngn5ZLQz8+5pq6TsfFRyOTC0d0pKLtObxUrIowCwKd28mic4Bxdd36nKSR MggtE+GKbUoz6whqNxlQM9voZsIoCSC0PS92ycWvZjhKEktGW7qdyFYiZPdjFB7jAdob g/QOKS2AFBkQg2iwebVVSYpJCotL7e0ca5qqdFR0FlNH5qtBCUoVuVCeQ/Ars4YiKXuO a44Zi9PtVRsZtyfVU6pipj0ViyNI7dpRnAFXGPOwKYA9I9qncoPc5KXBwAEoO1vc/o4h W43qijpHHoqRcssFiTYAmku4HKNDAWDp866AICR32u4agTwfMst1kdep+H3GiK3OlyXq fcpw== X-Gm-Message-State: AKwxytcbS+nfGXKgJAs94+qJ3zPjdQwKILraKDu9e4S9xZSCHDPXjPDT QExAV31hdAmPZvjgEhVzn/I= X-Google-Smtp-Source: ACJfBotS7Pzhq0edXiy1j5HaePkpX5V4ZjuVzhqgDONj/aEpCESDW9oIs/PGAV4US6X+ZuHtaMN82A== X-Received: by 10.159.229.22 with SMTP id s22mr19968966plq.202.1516080791199; Mon, 15 Jan 2018 21:33:11 -0800 (PST) Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp. [61.215.137.162]) by smtp.gmail.com with ESMTPSA id w124sm1680194pfw.90.2018.01.15.21.33.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Jan 2018 21:33:09 -0800 (PST) Date: Tue, 16 Jan 2018 14:33:05 +0900 From: Michael Paquier To: Bruce Momjian Cc: PostgreSQL-documentation , Stephen Frost , David Steele Subject: Re: Correction of intermediate certificate handling Message-ID: <20180116053305.GB2212@paquier.xyz> References: <20180116002238.GC12724@momjian.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <20180116002238.GC12724@momjian.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 15, 2018 at 07:22:38PM -0500, Bruce Momjian wrote: > I asked Stephen Frost and David Steele for details on the arcane art of > SSL certificate creation. They showed me scripts they use and explained > that they properly pass intermediate certificates to clients. The trick > was to use the v3_ca extension when creating root and intermediate > certificates. >=20 > My talk documents this behavior. In this talk: >=20 > https://momjian.us/main/writings/pgsql/tls.pdf >=20 > slide 47 and 49 use -extensions v3_ca. Slides 73 and 74 show that the > intermediate is not needed on the client if it is created with v3_ca and > exist on the server. Slide 75 shows that the server certificate must be > first in server.crt. >=20 > I have created the attached doc patch to add this information to our > docs. I would like to backpatch this since what we have now, while it > works, is inaccurate. I have spent some time looking at your patch, this gets a +1 from here. This bit is important. I am happy that your patch mentions that intermediate certificates avoid the need to store root ones on the client. Should the docs mention terms like "chain of trust"? Perhaps the docs could also include an example of command to create a root and an intermediate certificate in runtime.sgml or such? On top of that, src/test/ssl does not provide any kind of coverage for that. It would be an area of improvement for those tests. -- Michael --Y7xTucakfITjPcLV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlpdjpEACgkQnvQgOdby QH03rQ//eV9pxA2gxBPVA3k2J7yEpKz4sKJw+Xam8wVi2TeqKnJ6eqcXkwXWE+Mt eylCWlmCYLYZ3XzkZM/LpJylMyxKg1YRhvuoePJhQGyhmo+n9UACap8vjlCqhtoJ EgCTLDQEGLCVllCeOk5khfM/TOpQ2AQ64eFawoU0xqJwV7gWu3BcIid9FBaop6oq dOnApAgmrvHKrXr+JLTvJLtKL0Q79BCGpzqOiPzv4xI10tLZ3igR1F/+O4Rc5aEi JqQDX+Yv5esYcO1QSZd9MowfwZQCD+QgrKqFTTbWHLH6IlAC8g/9yATUe1HG6vaN jmIS25IkLQLkFwRM8R5I/Y3tJS+Y930f9Xtu9ruNU+q1hU0LEQjZWLmwkFI9LLW+ OSbQuMGWdriKviq5k4jAgI3ofyHcE9cMF8DDmLyDI1lwHJaeRJXMP7Mx5J4hDNL2 eaJ1isObXMmYknt44waM1w+rb3E3XezVZUqUANfHts43EyfzNqFQhpwRH0+7Imly 1K4h2x88IQ8UG6MjK1wyHP8s+gwPL0Q62nBfJru4jicn/1J3UNsQyZiPZ65SO+W4 c0s9dAH6T6pw98FBTYzvSPZdjx/muRDF4zIXT4RguzSg2p9Sdy3q1NIASzHiJ3jU XP+YLCTbsQ1PoRY2Pr/Qan2LcFXoQe4T2YwSGji1YpJGHNkGZgo= =xrja -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV--