On Sat, Nov 30, 2013 at 12:10:19PM -0500, Bruce Momjian wrote:
> > Drat, you're quite right. I've always included the full certificate
> > chain in client certs but it's in no way required.
> > 
> > I guess that pretty much means maintaining the status quo and documenting
> > it better.
> 
> I have developed the attached patch to document this behavior.  My goals
> were:
> 
> * clarify that a cert can match a remote intermediate or root certificate
> * clarify that the client cert must match a server root.crt
> * clarify that the server cert much match a client root.crt
> * clarify that the root certificate does not have to be specified
>   in the client or server cert as long as the remote end has the chain
>   to the root
> 
> Does it meet these goals?  Is it correct?

I have updated the patch, attached, to be clearer about the requirement
that intermediate certificates need a chain to root certificates.

-- 
  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
new file mode 100644
index 955f248..443a48e
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** ldap://ldap.acme.com/cn=dbserver,cn=host
*** 7121,7127 ****
     To allow server certificate verification, the certificate(s) of one or more
     trusted <acronym>CA</>s must be
     placed in the file <filename>~/.postgresql/root.crt</> in the user's home
!    directory. (On Microsoft Windows the file is named
     <filename>%APPDATA%\postgresql\root.crt</filename>.)
    </para>
  
--- 7121,7129 ----
     To allow server certificate verification, the certificate(s) of one or more
     trusted <acronym>CA</>s must be
     placed in the file <filename>~/.postgresql/root.crt</> in the user's home
!    directory. If intermediate <acronym>CA</>s appear in
!    <filename>root.crt</filename>, the file must also contain certificate
!    chains to their root <acronym>CA</>s. (On Microsoft Windows the file is named
     <filename>%APPDATA%\postgresql\root.crt</filename>.)
    </para>
  
*************** ldap://ldap.acme.com/cn=dbserver,cn=host
*** 7179,7193 ****
     <quote>intermediate</> certificate authority, rather than one that is
     directly trusted by the server.  To use such a certificate, append the
     certificate of the signing authority to the <filename>postgresql.crt</>
!    file, then its parent authority's certificate, and so on up to a
!    <quote>root</> authority that is trusted by the server.  The root
!    certificate should be included in every case where
!    <filename>postgresql.crt</> contains more than one certificate.
    </para>
  
    <para>
!    Note that <filename>root.crt</filename> lists the top-level CAs that are
!    considered trusted for signing server certificates.  In principle it need
     not list the CA that signed the client's certificate, though in most cases
     that CA would also be trusted for server certificates.
    </para>
--- 7181,7195 ----
     <quote>intermediate</> certificate authority, rather than one that is
     directly trusted by the server.  To use such a certificate, append the
     certificate of the signing authority to the <filename>postgresql.crt</>
!    file, then its parent authority's certificate, and so on up to a certificate
!    authority, <quote>root</> or <quote>intermediate</>, that is trusted by
!    the server, i.e. signed by a certificate in the server's
!    <filename>root.crt</filename> file.
    </para>
  
    <para>
!    Note that the client's <filename>~/.postgresql/root.crt</> lists the top-level CAs 
!    that are considered trusted for signing server certificates.  In principle it need
     not list the CA that signed the client's certificate, though in most cases
     that CA would also be trusted for server certificates.
    </para>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
new file mode 100644
index ab51782..4916837
*** a/doc/src/sgml/runtime.sgml
--- b/doc/src/sgml/runtime.sgml
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 1986,1995 ****
     <quote>intermediate</> certificate authority, rather than one that is
     directly trusted by clients.  To use such a certificate, append the
     certificate of the signing authority to the <filename>server.crt</> file,
!    then its parent authority's certificate, and so on up to a <quote>root</>
!    authority that is trusted by the clients.  The root certificate should
!    be included in every case where <filename>server.crt</> contains more than
!    one certificate.
    </para>
  
    <sect2 id="ssl-client-certificates">
--- 1986,1995 ----
     <quote>intermediate</> certificate authority, rather than one that is
     directly trusted by clients.  To use such a certificate, append the
     certificate of the signing authority to the <filename>server.crt</> file,
!    then its parent authority's certificate, and so on up to a certificate
!    authority, <quote>root</> or <quote>intermediate</>, that is trusted by
!    clients, i.e. signed by a certificate in the clients'
!    <filename>root.crt</filename> files.
    </para>
  
    <sect2 id="ssl-client-certificates">
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 2008,2014 ****
     SSL connection startup.  (See <xref linkend="libpq-ssl"> for a
     description of how to set up certificates on the client.)  The server will
     verify that the client's certificate is signed by one of the trusted
!    certificate authorities.  Certificate Revocation List (CRL) entries
     are also checked if the parameter <xref linkend="guc-ssl-crl-file"> is set.
     <!-- If this URL changes replace it with a URL to www.archive.org. -->
     (See <ulink
--- 2008,2017 ----
     SSL connection startup.  (See <xref linkend="libpq-ssl"> for a
     description of how to set up certificates on the client.)  The server will
     verify that the client's certificate is signed by one of the trusted
!    certificate authorities.  If intermediate <acronym>CA</>s appear in
!    <filename>root.crt</filename>, the file must also contain certificate
!    chains to their root <acronym>CA</>s.  Certificate Revocation List
!    (CRL) entries
     are also checked if the parameter <xref linkend="guc-ssl-crl-file"> is set.
     <!-- If this URL changes replace it with a URL to www.archive.org. -->
     (See <ulink
*************** pg_dumpall -p 5432 | psql -d postgres -p
*** 2026,2033 ****
    </para>
  
    <para>
!    Note that <filename>root.crt</filename> lists the top-level CAs that are
!    considered trusted for signing client certificates.  In principle it need
     not list the CA that signed the server's certificate, though in most cases
     that CA would also be trusted for client certificates.
    </para>
--- 2029,2037 ----
    </para>
  
    <para>
!    Note that the server's <filename>root.crt</filename> lists the top-level
!    CAs that are considered trusted for signing client certificates.
!    In principle it need
     not list the CA that signed the server's certificate, though in most cases
     that CA would also be trusted for client certificates.
    </para>
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to