pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
ssl client cert authentication
4+ messages / 3 participants
[nested] [flat]

* ssl client cert authentication
@ 2010-11-01 16:14 Ray Stell <stellr@cns.vt.edu>
  2010-11-01 16:46 ` Re: ssl client cert authentication Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 4+ messages in thread

From: Ray Stell @ 2010-11-01 16:14 UTC (permalink / raw)
  To: pgsql-admin@postgresql.org

Someone asked about ssl client cert auth recently.  I got
this to work, but something tripped me up.

http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html

states (very clearly, btw) that, "To require the client to supply a
trusted certificate, place certificates of the certificate authorities
(CAs) you trust in the file root.crt in the data directory."  I had
ASS-U-MEd that root.crt would go in .postgresql as it does for encryption.

This begs the question, why two copies of the same file?



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: ssl client cert authentication
  2010-11-01 16:14 ssl client cert authentication Ray Stell <stellr@cns.vt.edu>
@ 2010-11-01 16:46 ` Tom Lane <tgl@sss.pgh.pa.us>
  2010-11-01 19:15   ` Re: ssl client cert authentication Ray Stell <stellr@cns.vt.edu>
  0 siblings, 1 reply; 4+ messages in thread

From: Tom Lane @ 2010-11-01 16:46 UTC (permalink / raw)
  To: Ray Stell <stellr@cns.vt.edu>; +Cc: pgsql-admin@postgresql.org

Ray Stell <stellr@cns.vt.edu> writes:
> Someone asked about ssl client cert auth recently.  I got
> this to work, but something tripped me up.

> http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html

> states (very clearly, btw) that, "To require the client to supply a
> trusted certificate, place certificates of the certificate authorities
> (CAs) you trust in the file root.crt in the data directory."  I had
> ASS-U-MEd that root.crt would go in .postgresql as it does for encryption.

> This begs the question, why two copies of the same file?

The one in ~/.postgresql is for client usage.  The one in $PGDATA is for
the server's use.  There's no reason to assume they'd be the same.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: ssl client cert authentication
  2010-11-01 16:14 ssl client cert authentication Ray Stell <stellr@cns.vt.edu>
  2010-11-01 16:46 ` Re: ssl client cert authentication Tom Lane <tgl@sss.pgh.pa.us>
@ 2010-11-01 19:15   ` Ray Stell <stellr@cns.vt.edu>
  2011-01-18 02:31     ` Re: ssl client cert authentication Bruce Momjian <bruce@momjian.us>
  0 siblings, 1 reply; 4+ messages in thread

From: Ray Stell @ 2010-11-01 19:15 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin@postgresql.org

On Mon, Nov 01, 2010 at 12:46:33PM -0400, Tom Lane wrote:
> Ray Stell <stellr@cns.vt.edu> writes:
> > Someone asked about ssl client cert auth recently.  I got
> > this to work, but something tripped me up.
> 
> > http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html
> 
> > states (very clearly, btw) that, "To require the client to supply a
> > trusted certificate, place certificates of the certificate authorities
> > (CAs) you trust in the file root.crt in the data directory."  I had
> > ASS-U-MEd that root.crt would go in .postgresql as it does for encryption.
> 
> > This begs the question, why two copies of the same file?
> 
> The one in ~/.postgresql is for client usage.  The one in $PGDATA is for
> the server's use.  There's no reason to assume they'd be the same.
> 
> 			regards, tom lane

I think I see where I went off:
 31.17. SSL Support
Changing this to: 
 31.17. Client SSL Support
would be helpful.  Also, 
 31.17.4. SSL File Usage
might be:
 31.17.4. SSL Client File Usage
They did this in the server section, so I'm not completely nuts:
 17.8.2. SSL Server File Usage

In hindsight it is very clear.  Chapter 17 is on the server and 31 is on the
client.  Adding those section title words would have helped me stay on 
course. 

Another way of providing clue would be to add $PGDATA somewhere in Table
17-3. SSL Server File Usage.  They did that sort of thing on the client side
in Table 31-4. Libpq/Client SSL File Usage.



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: ssl client cert authentication
  2010-11-01 16:14 ssl client cert authentication Ray Stell <stellr@cns.vt.edu>
  2010-11-01 16:46 ` Re: ssl client cert authentication Tom Lane <tgl@sss.pgh.pa.us>
  2010-11-01 19:15   ` Re: ssl client cert authentication Ray Stell <stellr@cns.vt.edu>
@ 2011-01-18 02:31     ` Bruce Momjian <bruce@momjian.us>
  0 siblings, 0 replies; 4+ messages in thread

From: Bruce Momjian @ 2011-01-18 02:31 UTC (permalink / raw)
  To: Ray Stell <stellr@cns.vt.edu>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs

Ray Stell wrote:
> On Mon, Nov 01, 2010 at 12:46:33PM -0400, Tom Lane wrote:
> > Ray Stell <stellr@cns.vt.edu> writes:
> > > Someone asked about ssl client cert auth recently.  I got
> > > this to work, but something tripped me up.
> > 
> > > http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html
> > 
> > > states (very clearly, btw) that, "To require the client to supply a
> > > trusted certificate, place certificates of the certificate authorities
> > > (CAs) you trust in the file root.crt in the data directory."  I had
> > > ASS-U-MEd that root.crt would go in .postgresql as it does for encryption.
> > 
> > > This begs the question, why two copies of the same file?
> > 
> > The one in ~/.postgresql is for client usage.  The one in $PGDATA is for
> > the server's use.  There's no reason to assume they'd be the same.
> > 
> > 			regards, tom lane
> 
> I think I see where I went off:
>  31.17. SSL Support
> Changing this to: 
>  31.17. Client SSL Support
> would be helpful.  Also, 
>  31.17.4. SSL File Usage
> might be:
>  31.17.4. SSL Client File Usage
> They did this in the server section, so I'm not completely nuts:
>  17.8.2. SSL Server File Usage
> 
> In hindsight it is very clear.  Chapter 17 is on the server and 31 is on the
> client.  Adding those section title words would have helped me stay on 
> course. 
> 
> Another way of providing clue would be to add $PGDATA somewhere in Table
> 17-3. SSL Server File Usage.  They did that sort of thing on the client side
> in Table 31-4. Libpq/Client SSL File Usage.

These are all very good ideas and I have applied them for 9.1 in the
attached patch.  I also found a few libpq titles that needed
capitalization, which is also in the patch. Thanks for the ideas.

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

  + It's impossible for everything to be true. +

Attachments:

/rtmp/libpq (text/x-diff, 5.5K) download diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index fe661b8..1606a56 100644 *** /tmp/pgdiff.4616/aPwGCb_libpq.sgml Mon Jan 17 21:29:06 2011 --- doc/src/sgml/libpq.sgml Mon Jan 17 21:04:29 2011 *************** ldap://ldap.acme.com/cn=dbserver,cn=host *** 6641,6647 **** </para> <sect2 id="libq-ssl-certificates"> ! <title>Certificate verification</title> <para> By default, <productname>PostgreSQL</> will not perform any verification of --- 6641,6647 ---- </para> <sect2 id="libq-ssl-certificates"> ! <title>Client Verification of Server Certificates</title> <para> By default, <productname>PostgreSQL</> will not perform any verification of *************** ldap://ldap.acme.com/cn=dbserver,cn=host *** 6696,6702 **** </sect2> <sect2 id="libpq-ssl-clientcert"> ! <title>Client certificates</title> <para> If the server requests a trusted client certificate, --- 6696,6702 ---- </sect2> <sect2 id="libpq-ssl-clientcert"> ! <title>Client Certificates</title> <para> If the server requests a trusted client certificate, *************** ldap://ldap.acme.com/cn=dbserver,cn=host *** 6738,6744 **** </sect2> <sect2 id="libpq-ssl-protection"> ! <title>Protection provided in different modes</title> <para> The different values for the <literal>sslmode</> parameter provide different --- 6738,6744 ---- </sect2> <sect2 id="libpq-ssl-protection"> ! <title>Protection Provided in Different Modes</title> <para> The different values for the <literal>sslmode</> parameter provide different *************** ldap://ldap.acme.com/cn=dbserver,cn=host *** 6746,6752 **** protection against three types of attacks: </para> <table id="libpq-ssl-protect-attacks"> ! <title>SSL attacks</title> <tgroup cols="2"> <thead> <row> --- 6746,6752 ---- protection against three types of attacks: </para> <table id="libpq-ssl-protect-attacks"> ! <title>SSL Attacks</title> <tgroup cols="2"> <thead> <row> *************** ldap://ldap.acme.com/cn=dbserver,cn=host *** 6821,6827 **** </para> <table id="libpq-ssl-sslmode-statements"> ! <title>SSL mode descriptions</title> <tgroup cols="4"> <thead> <row> --- 6821,6827 ---- </para> <table id="libpq-ssl-sslmode-statements"> ! <title>SSL Mode Descriptions</title> <tgroup cols="4"> <thead> <row> *************** ldap://ldap.acme.com/cn=dbserver,cn=host *** 6912,6918 **** </sect2> <sect2 id="libpq-ssl-fileusage"> ! <title>SSL File Usage</title> <table id="libpq-ssl-file-usage"> <title>Libpq/Client SSL File Usage</title> <tgroup cols="3"> --- 6912,6918 ---- </sect2> <sect2 id="libpq-ssl-fileusage"> ! <title>SSL Client File Usage</title> <table id="libpq-ssl-file-usage"> <title>Libpq/Client SSL File Usage</title> <tgroup cols="3"> *************** ldap://ldap.acme.com/cn=dbserver,cn=host *** 6958,6964 **** </sect2> <sect2 id="libpq-ssl-initialize"> ! <title>SSL library initialization</title> <para> If your application initializes <literal>libssl</> and/or --- 6958,6964 ---- </sect2> <sect2 id="libpq-ssl-initialize"> ! <title>SSL Library Initialization</title> <para> If your application initializes <literal>libssl</> and/or diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 8911e99..9b92bec 100644 *** /tmp/pgdiff.4616/QgCZ3a_runtime.sgml Mon Jan 17 21:29:06 2011 --- doc/src/sgml/runtime.sgml Mon Jan 17 21:18:42 2011 *************** $ <userinput>kill -INT `head -1 /usr/loc *** 1770,1796 **** <tbody> <row> ! <entry><filename>server.crt</></entry> <entry>server certificate</entry> <entry>sent to client to indicate server's identity</entry> </row> <row> ! <entry><filename>server.key</></entry> <entry>server private key</entry> <entry>proves server certificate was sent by the owner; does not indicate certificate owner is trustworthy</entry> </row> <row> ! <entry><filename>root.crt</></entry> <entry>trusted certificate authorities</entry> <entry>checks that client certificate is signed by a trusted certificate authority</entry> </row> <row> ! <entry><filename>root.crl</></entry> <entry>certificates revoked by certificate authorities</entry> <entry>client certificate must not be on this list</entry> </row> --- 1770,1796 ---- <tbody> <row> ! <entry><filename>$PGDATA/server.crt</></entry> <entry>server certificate</entry> <entry>sent to client to indicate server's identity</entry> </row> <row> ! <entry><filename>$PGDATA/server.key</></entry> <entry>server private key</entry> <entry>proves server certificate was sent by the owner; does not indicate certificate owner is trustworthy</entry> </row> <row> ! <entry><filename>$PGDATA/root.crt</></entry> <entry>trusted certificate authorities</entry> <entry>checks that client certificate is signed by a trusted certificate authority</entry> </row> <row> ! <entry><filename>$PGDATA/root.crl</></entry> <entry>certificates revoked by certificate authorities</entry> <entry>client certificate must not be on this list</entry> </row>
^ permalink raw reply [nested|flat] 4+ messages in thread


end of thread, other threads:[~2011-01-18 02:31 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-11-01 16:14 ssl client cert authentication Ray Stell <stellr@cns.vt.edu>
2010-11-01 16:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-11-01 19:15   ` Ray Stell <stellr@cns.vt.edu>
2011-01-18 02:31     ` Bruce Momjian <bruce@momjian.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox