On Fri, Jun 12, 2020 at 04:17:56PM -0400, Chapman Flack wrote:
> On 06/12/20 15:13, Bruce Momjian wrote:
> > Without that ability, every client would need be changed as soon as the
> > server certificate was changed. Allowing intermediate certificates to
> > function as root certificates would
On 06/12/20 16:17, Chapman Flack wrote:
> reason. Typically that reason is that it has been placed in a file that
> can only be edited by the admin who decides what certs to trust. By
> editing it into that file, that responsible person has vouched for it,
> and /that/ is why the TLS client should
On 06/12/20 15:13, Bruce Momjian wrote:
> On Wed, Jun 3, 2020 at 07:57:16PM -0400, Chapman Flack wrote:
>> here is a root.crt file for libpq containing only this exact cert, I
>> want libpq to connect only ever to this server with this cert and nothing
>> else. It's a pain because I have to roll
On Wed, Jun 3, 2020 at 07:57:16PM -0400, Chapman Flack wrote:
> For example, we might agree that it is safe to trust nothing but the
> end-entity cert of my server itself. I made a server, here is its cert,
> here is a root.crt file for libpq containing only this exact cert, I
> want libpq to
Chapman Flack writes:
> Sure. It seems sensible to me to start by documenting /what/ it is doing
> now, and to what extent that should be called "its standard behavior"
> versus "the way libpq is calling it", because even if nothing is to be
> changed, there will be people who need to be able to
On 06/04/20 18:03, Tom Lane wrote:
> It's possible that we could force openssl to validate cases it doesn't
> accept now. Whether we *should* deviate from its standard behavior is
> a fairly debatable question though. I would not be inclined to do so
> unless we find that many other consumers of
Chapman Flack writes:
> On 06/04/20 17:31, Andrew Dunstan wrote:
>> Do we actually do any of this sort of thing? I confess my impression was
>> this is all handled by the openssl libraries, we just hand over the
>> certs and let openssl do its thing. Am I misinformed about that?
> By analogy to
On 06/04/20 17:31, Andrew Dunstan wrote:
> Do we actually do any of this sort of thing? I confess my impression was
> this is all handled by the openssl libraries, we just hand over the
> certs and let openssl do its thing. Am I misinformed about that?
I haven't delved very far into the code yet
On 6/3/20 7:57 PM, Chapman Flack wrote:
>
> In an ideal world, I think libpq would be using this algorithm:
>
> I'm looking at the server's certificate, s.
> Is s unexpired and in the trust file? If so, SUCCEED.
>
> otherwise, loop:
> get issuer certificate i from s (if s is
On 06/04/20 11:04, Laurenz Albe wrote:
> I was referring to the wish to *not* use a self-signed CA certificate,
> but an intermediate certificate as the ultimate authority, based on
> a distrust of the certification authority that your organization says
> you should trust.
Are you aware of any
On Thu, 2020-06-04 at 08:25 -0400, Chapman Flack wrote:
> > I feel bad about bending the basic idea of certificates and trust to suit
> > some misbegotten bureaucratic constraints on good security.
>
> Can you elaborate on what, in the email message you replied to here,
> represented a bending of
On 06/04/20 02:07, Laurenz Albe wrote:
> I feel bad about bending the basic idea of certificates and trust to suit
> some misbegotten bureaucratic constraints on good security.
Can you elaborate on what, in the email message you replied to here,
represented a bending of the basic idea of
On Wed, 2020-06-03 at 19:57 -0400, Chapman Flack wrote:
> Ok, so a person in the situation described here, who is not in a position
> to demand changes in an organizational policy (whether or not it seems
> ill-conceived to you or even to him/her), is facing this question:
>
> What are the
On 06/03/20 08:07, Ants Aasma wrote:
> I think the "why" the org cert is not root was already made clear, that is
> the copmany policy.
Thank you, yes, that was what I had intended to convey, and you have saved
me finishing a weedsier follow-up message hoping to convey it better.
> I don't think
On Wed, Jun 3, 2020 at 03:07:30PM +0300, Ants Aasma wrote:
> On Tue, 2 Jun 2020 at 20:14, Bruce Momjian wrote:
>
> The server certificate should be issued by a certificate authority root
> outside of your organization only if you want people outside of your
> organization to trust
On Tue, 2 Jun 2020 at 20:14, Bruce Momjian wrote:
> The server certificate should be issued by a certificate authority root
> outside of your organization only if you want people outside of your
> organization to trust your server certificate, but you are then asking
> for the client to only
On Tue, May 26, 2020 at 10:13:56AM -0400, Chapman Flack wrote:
> At $work, when I make a certificate request and send it off to our
> own in-house bureau of making certificates happen, what you might
> expect is that they would be running the first level of CA right
> in house (and IIRC that was
On 05/26/20 09:35, Andrew Dunstan wrote:
> The trouble is I think you have it the wrong way round. It makes sense
> to give less trust to a non-root CA than to one of its up-chain
> authorities, e.g. only trust it for certain domains, or for a lesser
> period of time. But it doesn't seem to make
On 5/25/20 3:32 PM, Chapman Flack wrote:
> On 05/25/20 15:15, Chapman Flack wrote:
>> Does that mean it also would fail if I directly put the server's
>> end-entity cert there?
>>
>> Would I have to put all three of WE ISSUE TO ORGS LIKE YOURS,
>> WE ISSUE TO LOTS, and WE ISSUE TO EVERYBODY in
On 05/26/20 02:05, Craig Ringer wrote:
> The main reason to put intermediate certificates in the root.crt is that it
> allows PostgreSQL to supply the whole certificate chain to a client during
Hold on a sec; you're not talking about what I'm talking about, yet.
Yes, you have make the chain
On Tue, 26 May 2020 at 11:43, Chapman Flack wrote:
> On 05/25/20 23:22, Laurenz Albe wrote:
> > I don't know if there is a way to get this to work, but the
> > fundamental problem seems that you have got the system wrong.
> >
> > If you don't trust WE ISSUE TO EVERYBODY, then you shouldn't use
>
On 05/26/20 00:07, Isaac Morland wrote:
> What about the SSH model? In the Postgres context, this would basically be
> a table containing authorized certificates for each user. Upon receiving a
> connection attempt, look up the user and the presented certificate and see
> if it is one of the
On 05/26/20 00:07, Alvaro Herrera wrote:
>> If the libpq root.crt file can be made to work similarly to a
>> Java trustStore, that expands the possible solution space.
>
> If I understand you correctly, you want a file in which you drop any of
> these intermediate CA's cert in, causing the server
On Tue, 26 May 2020 at 00:08, Alvaro Herrera
wrote:
> On 2020-May-25, Chapman Flack wrote:
>
> > If the libpq root.crt file can be made to work similarly to a
> > Java trustStore, that expands the possible solution space.
>
> If I understand you correctly, you want a file in which you drop any
On 2020-May-25, Chapman Flack wrote:
> If the libpq root.crt file can be made to work similarly to a
> Java trustStore, that expands the possible solution space.
If I understand you correctly, you want a file in which you drop any of
these intermediate CA's cert in, causing the server to trust a
What about the SSH model? In the Postgres context, this would basically be
a table containing authorized certificates for each user. Upon receiving a
connection attempt, look up the user and the presented certificate and see
if it is one of the authorized ones. If so, do the usual verification
On 05/25/20 23:22, Laurenz Albe wrote:
> I don't know if there is a way to get this to work, but the
> fundamental problem seems that you have got the system wrong.
>
> If you don't trust WE ISSUE TO EVERYBODY, then you shouldn't use
> it as a certification authority.
That's a reasonable
On Tue, May 26, 2020 at 05:22:13AM +0200, Laurenz Albe wrote:
> On Mon, 2020-05-25 at 15:15 -0400, Chapman Flack wrote:
> > Certificates I get at $work come four layers deep:
> >
> >
> > Self-signed CA cert from "WE ISSUE TO EVERYBODY.COM"
> >
> > Intermediate from "WE ISSUE TO LOTS OF
On Mon, 2020-05-25 at 15:15 -0400, Chapman Flack wrote:
> Certificates I get at $work come four layers deep:
>
>
> Self-signed CA cert from "WE ISSUE TO EVERYBODY.COM"
>
> Intermediate from "WE ISSUE TO LOTS OF FOLKS.COM"
>
> Intermediate from "WE ISSUE TO ORGS LIKE YOURS.COM"
>
>
On 05/25/20 22:03, Bruce Momjian wrote:
> Did you review the PG documentation about intermediate certificates?
>
> https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CERTIFICATE-CREATION
AFAICT, there isn't much in that section to apply to my question.
> Is there a specific question you
On Mon, May 25, 2020 at 03:32:52PM -0400, Chapman Flack wrote:
> On 05/25/20 15:15, Chapman Flack wrote:
> > Does that mean it also would fail if I directly put the server's
> > end-entity cert there?
> >
> > Would I have to put all three of WE ISSUE TO ORGS LIKE YOURS,
> > WE ISSUE TO LOTS, and
On 05/25/20 15:15, Chapman Flack wrote:
> Does that mean it also would fail if I directly put the server's
> end-entity cert there?
>
> Would I have to put all three of WE ISSUE TO ORGS LIKE YOURS,
> WE ISSUE TO LOTS, and WE ISSUE TO EVERYBODY in the root.crt file
> in order for verification to
Certificates I get at $work come four layers deep:
Self-signed CA cert from "WE ISSUE TO EVERYBODY.COM"
Intermediate from "WE ISSUE TO LOTS OF FOLKS.COM"
Intermediate from "WE ISSUE TO ORGS LIKE YOURS.COM"
End-entity cert for my server.
Until today, we had the topmost,
33 matches
Mail list logo
