more on makecert and pgkeygen

From: Bear Giles <bgiles(at)coyotesong(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: more on makecert and pgkeygen
Date: 2002-05-20 15:46:33
Message-ID: 200205201546.JAA13581@eris.coyotesong.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've been giving some more thought to the makecert (server)
and pgkeygen (client) programs, and may have a clean solution
to the problem of mapping certs to pgusers.

1) makecert will have the ability to generate two different types
of certs: root (CA) certs and server certs. The server certs
are signed by the root cert and server certs can be fully
verified by adding the root cert to the user's ~/.postgresql
directory.

This tool would be run once soon after installation.

2) pgkeygen will create basic self-signed certs. These certs
must be signed by the DBA before they're usable.

This tool would be run once by each user.

3) an third tool (signcert?) is used to sign the user certs with
the root cert created by makecert. This allows the backend
to require client certs be signed by a trusted CA... and to
trust the pguser string within them. Clients could still use
SSL without client certs, but it couldn't be used for
authentication.

This tool would take two arguments - the client's self-signed
(or previously signed) cert and a pguser string. The cert
would be modified to include an altSubjName extension that
identifies the pguser (e.g., "postgresql: pguser") and then
signed.

This tool would be run as-needed by the DBA, and would be
required to support SSL-based authentication.

There are other issues with CRLs, renewals, etc., but they can
be pushed off for a while.

Bear

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-05-20 16:16:44 Re: timestamp-to-date broken in current sources
Previous Message Hannu Krosing 2002-05-20 15:39:28 Re: Unbounded (Possibly) Database Size Increase - Toasting