Subject: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Wed, 29 Oct 2025 20:19:49 +0100

Hi,

While working on a validator for keycloak[1] with libpq-oauth I find
out that to allow a self-signed certificated I had to set the CA on the
client but for this was required to also set the PGOAUTHDEBUG=UNSAFE
which generated a lot of information on the client side that I didn't
need for my testing and work.

This patch basically remove the need of setting the PGOAUTHDEBUG=UNSAFE
to be able to use PGOAUTHCAFILE.

I'm not sure if where I put the documentation is the right place, I
would like to have some opinions on that matter too.

[1] https://github.com/cloudnative-pg/postgres-keycloak-oauth-validator

-- 
Jonathan Gonzalez V. <[email-masked]>
From b32a1ad93f933fa319ff29e15299659d67de4d22 Mon Sep 17 00:00:00 2001
From: "Jonathan Gonzalez V." <[email-masked]>
Date: Wed, 29 Oct 2025 16:54:42 +0100
Subject: [PATCH v1 1/1] libpq-oauth: allow changing the CA when not in debug
 mode

Allowing to set a CA enables users environment like companies with
internal CA or developers working on their own local system while
using a self-signed CA and don't need to see all the debug messages
while testing inside an internal environment.

Signed-off-by: Jonathan Gonzalez V. <[email-masked]>
---
 doc/src/sgml/libpq.sgml                 | 23 +++++++++++++++++------
 src/interfaces/libpq-oauth/oauth-curl.c | 20 +++++++-------------
 2 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 5bf59a19855..c3fe9d5478a 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -10520,12 +10520,6 @@ typedef struct PGoauthBearerRequest
        permits the use of unencrypted HTTP during the OAuth provider exchange
       </para>
      </listitem>
-     <listitem>
-      <para>
-       allows the system's trusted CA list to be completely replaced using the
-       <envar>PGOAUTHCAFILE</envar> environment variable
-      </para>
-     </listitem>
      <listitem>
       <para>
        prints HTTP traffic (containing several critical secrets) to standard
@@ -10547,6 +10541,23 @@ typedef struct PGoauthBearerRequest
     </para>
    </warning>
   </sect2>
+  <sect2 id="libpq-oauth-environment">
+   <title>Environment variables</title>
+   <para>
+    The behavior of the OAuth calls may be affected by the following variables:
+    <variablelist>
+     <varlistentry>
+      <term><envar>PGOAUTHCAFILE</envar></term>
+      <listitem>
+       <para>
+        Allows to specify the path to a CA file that will be used by the client
+        to verify the certificate from the OAuth server side.
+       </para>
+      </listitem>
+     </varlistentry>
+    </variablelist>
+   </para>
+  </sect2>
  </sect1>

diff --git a/src/interfaces/libpq-oauth/oauth-curl.c b/src/interfaces/libpq-oauth/oauth-curl.c
index aa50b00d053..b27a269c962 100644
--- a/src/interfaces/libpq-oauth/oauth-curl.c
+++ b/src/interfaces/libpq-oauth/oauth-curl.c
@@ -1704,6 +1704,8 @@ debug_callback(CURL *handle, curl_infotype type, char *data, size_t size,
 static bool
 setup_curl_handles(struct async_ctx *actx)
 {
+	const char *env;
+
 	/*
 	 * Create our multi handle. This encapsulates the entire conversation with
 	 * libcurl for this connection.
@@ -1792,20 +1794,12 @@ setup_curl_handles(struct async_ctx *actx)
 	}
 
 	/*
-	 * If we're in debug mode, allow the developer to change the trusted CA
-	 * list. For now, this is not something we expose outside of the UNSAFE
-	 * mode, because it's not clear that it's useful in production: both libpq
-	 * and the user's browser must trust the same authorization servers for
-	 * the flow to work at all, so any changes to the roots are likely to be
-	 * done system-wide.
+	 * Allow to change the trusted CA even if we're not in debug mode, this help
+	 * to make it easy to work on environments were the CA could internal and
+	 * not available on every system, like big companies with airgap systems.
 	 */
-	if (actx->debugging)
-	{
-		const char *env;
-
-		if ((env = getenv("PGOAUTHCAFILE")) != NULL)
-			CHECK_SETOPT(actx, CURLOPT_CAINFO, env, return false);
-	}
+	if ((env = getenv("PGOAUTHCAFILE")) != NULL)
+		CHECK_SETOPT(actx, CURLOPT_CAINFO, env, return false);
 
 	/*
 	 * Suppress the Accept header to make our request as minimal as possible.
-- 
2.51.0

---

From: Daniel Gustafsson <[email-masked]>
Date: Mon, 3 Nov 2025 15:24:37 +0100

> On 29 Oct 2025, at 20:19, Jonathan Gonzalez V. <[email-masked]> wrote:

> to be able to use PGOAUTHCAFILE.

If we do allow this (IIRC we did discuss during development to allow this but
erred on the side of caution) it should probably be made into a env var *and*
connection param setting like how libpq is otherwise configured?

--
Daniel Gustafsson

---

From: Jacob Champion <[email-masked]>
Date: Mon, 3 Nov 2025 08:24:29 -0800

On Mon, Nov 3, 2025 at 6:24 AM Daniel Gustafsson <[email-masked]> wrote:
> erred on the side of caution)

Yeah, the replaced comment explains it. The assumption is that
whatever device you're using to log in (presumably a browser, not
Curl) has to have the certificates figured out for production use, so
overriding it for Curl alone is probably only good enough for dev use.

But I ran into this annoyance (wanted to override the CA for temporary
development purposes, got sprayed with debug output) during a demo
just last month, so I'm in favor of doing something to make this
easier.

> it should probably be made into a env var *and*

I'm still not quite sure about the target audience. If it's just for
developers, I don't necessarily see a need to take up connection
string space (or provide our proxies with yet another setting to worry
about).

Jonathan, the patch itself claims to handle two cases. What's the
production use case where a company has its own CA isolated from the
Internet but isn't willing to add that CA to the system trust?

The reason I ask is that we'd briefly talked about splitting
PGOAUTHDEBUG into more granular settings than just "off" and "UNSAFE".
So if this is a developer-only thing, we could maybe put some more
design work into the list of debug features. That list currently
includes the stderr spray, turning off HTTPS, allowing sub-second ping
intervals, overriding the CA, debugging libpq-oauth link failures,
counting the calls to the flow -- all of which run the gamut from
"completely unsafe" to "completely safe".

Thanks!
--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Mon, 3 Nov 2025 16:53:35 +0000

I was thinking about asking something similar.

In our case, we have two problematic use cases: quick demo setups and CI.

When you start up a simple keycloak instance, you have two easy
options: either use http, or self-signed certificates.

For a CI setup, I can create disposable containers, generate
self-signed certificates, make the OS trust them, and run the tests
that way. But it's complex, and even if it were simple, it's not ideal
for a quick "how to set up a test environment" guide. I also
considered creating a demo docker-compose setup, but even with that, I
can't make the user's browser trust the certificates.

I also do not want to instruct users to specify this variable, as it
provides tons of debug output, some of that is sensitive tokens, and
the users might now know that.

> PGOAUTHDEBUG into more granular settings than just "off" and "UNSAFE".

That's more similar to the direction I considered going, I was
thinking about adding a PGOAUTHDEBUG=http option. That way there's no
need for self signed certificates, and it's easier to explain to users
that this just allows a less secure quick http setup.

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Tue, 04 Nov 2025 14:00:55 +0100

Hi!
> just last month, so I'm in favor of doing something to make this

I was creating some demo too, at the beginning was really useful, but
after some seconds, I used to lose the URL and the code, the URL wasn't
an issue later, but the code it was.

> Internet but isn't willing to add that CA to the system trust?

Well, there's a couple of cases, I figure out after the first email,
thanks to Alvaro, that I wasn't clear in the comments, probably I
should change it, will try to describe a few cases that I've seen over
the years.

* In Kubernetes, even with a network isolation, people use to prefer
having TLS connections, just because it's the standard, but in internal
communications (between namespaces and pods), these domains contain the
format: <service>.<namespace>.svc.<clustername>.local, as you can
already imagine, this kind of domain cannot be verified by an external
CA, but they can be generated and verified with an internal CA. Now the
question is, why they  don't add this CA to every distribution? The
defacto standard way to do this in Kubernetes is to take the CA from a
ConfigMap or Secret (objects that can provide content inside the
infrastructure) and deploy this dynamically inside the Pod, so, to
indicate the path to this file, the standard is to use an environment
variable, in this case, if the content of the ConfigMap or Secret
changes, this will be refreshed inside the Pod too.

* Big companies like those managing credit cards or big banks, use to
have air gap environment, which may have exactly the same problem while
communicating internally, the CA cannot verify an internal domain, on
these cases the CA is usually moved around and installed in a specific
path and installed on specific path and not the system path (usually
because of compliant reasons), meaning that you will actually have to
provide with a variable/configuration/environment the path to the CA.

* Development cases, I think this is clear, but even when you're doing
development, you'll be using a self-signed certificate, but doing
developing and losing URL and the code it can be really common, it
happened to me many times and it wasn't nice looking for the code.

* CI cases, here, you'll not have time to get a certificate to just
trigger an action against a one time domain, usually with a random
domain to not conflict with other CI running at the same time, and you
should never expose sensitive information on the CI output like the one
exposes when enabling PGOAUTHDEBUG="UNSAFE"

> PGOAUTHDEBUG into more granular settings than just "off" and

I was thinking the same for another patch that will require discussion
for sure, but it's something similar to add some levels of debug, for
example, when you want to have the tokens or when you only want to see
the URLs used to negotiate (which are really useful when working with
the OAuth flows) or the deep one when you want to see the tokens.

> "completely unsafe" to "completely safe".

Ho! where can I see this list? I'd love to help with something here!

I'm more than open to keep discussing this, because I can see that many
people will be affected by the same, specially in the Kubernetes world.

Thank your for looking at this!

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 4 Nov 2025 14:26:00 +0100

> On 4 Nov 2025, at 14:00, Jonathan Gonzalez V. <[email-masked]> wrote:

> Ho! where can I see this list? I'd love to help with something here!

There is no documented list as far as I can remember, but look for calls to
oauth_unsafe_debugging_enabled() in:

https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-auth-oauth.c

And conditionals checking the actx->debugging variable in:

https://github.com/postgres/postgres/blob/master/src/interfaces/libpq-oauth/oauth-curl.c

--
Daniel Gustafsson

---

From: Jacob Champion <[email-masked]>
Date: Wed, 19 Nov 2025 10:55:43 -0800

On Tue, Nov 4, 2025 at 5:02 AM Jonathan Gonzalez V.
> changes, this will be refreshed inside the Pod too.

Okay, that's good to know. But I'm still missing how the end user (a
human) trusts that magic CA within the browser or device they use to
finish the actual flow?

> provide with a variable/configuration/environment the path to the CA.

Same question as above, but I'm slowly being convinced that this
thread needs to remain separate from the PGOAUTHDEBUG split
discussion, even if they're related.

This might be a silly-small example, but I've added a stub spec:

    https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature

> happened to me many times and it wasn't nice looking for the code.

Right.

> exposes when enabling PGOAUTHDEBUG="UNSAFE"

Who's running the CI, and how do OAuth and Device Authorization factor
into it? (And why would a human user be okay with feeding their
privileges into an authorization server with a random-looking host
name every time they run it?)

> the OAuth flows) or the deep one when you want to see the tokens.

I think that's reached critical mass, then.

> Thank your for looking at this!

Thanks for the discussion!

--Jacob

---

From: Jacob Champion <[email-masked]>
Date: Wed, 19 Nov 2025 11:26:02 -0800

On Mon, Nov 3, 2025 at 8:53 AM Zsolt Parragi <[email-masked]> wrote:
> That's more similar to the direction I considered going,

I've added a stub summary for this, too:

    https://wiki.postgresql.org/wiki/Proposal:_Split_up_PGOAUTHDEBUG

> I was

I think it's important to keep unsafe options labelled as such, but I
agree this would be helpful.

I'm not sure if we have prior art for expressing bitflags in Postgres
envvars, other than maybe PGREQUIREAUTH. A comma-separated list would
be easy to do. We could name these things according to whether they're
unsafe or not, like

    PGOAUTHDEBUG=UNSAFE-http,UNSAFE-trace,print-counts

Or maybe that's too verbose, and we could say that to use any of the
unsafe options, you have to say it up front:

    # http and trace are dangerous
    PGOAUTHDEBUG=UNSAFE:http,trace,print-counts
    # these two are safe
    PGOAUTHDEBUG=print-counts,print-plugin-errors

Or something else? Since this is developer-facing, I don't think it
has to necessarily be intuitive for end users, as long as the lack of
safety remains obvious to them. We can just focus on ergonomics for
us.

Thanks,
--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Fri, 12 Dec 2025 11:05:15 +0000

Hello

I implemented a simple patch based on the above suggestion
(PGOAUTHDEBUG=UNSAFE:http...). I did not update the documentation yet,
let's see what everyone thinks about it before that, and I also have
some concerns/questions.

I added the new functions into a common source file which gets
included in both the oauth module and libpq. I'm not entirely happy
about this, but I didn't see a better way without duplicating the
code.

My concern,  which is also there with the current version: is an
environment variable the best way to control these settings in a
library included into many applications? Wouldn't it be better to make
these settings in libpq (or the oauth module), and only add the
environment variables to psql?

This can be used to inject a CA into an application without the user
noticing it, or without the application developer being aware of the
possibility. With the current single-value variable, it is already
possible, and in an application without a visible standard output, it
is already hidden. But by splitting the setting into multiple flags,
this can go unnoticed even in a console application.

Another question is what to do with the CA file - currently it remains
a separate (environment) variable, but maybe it could be included in
the option string instead:
PGOAUTHDEBUG=UNSAFE:custom-ca=/path/to/the/file

What do you think about it?

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Sun, 14 Dec 2025 12:08:32 +0100

Hi!

Sorry for the delayed answer!

> human) trusts that magic CA within the browser or device they use to

More than the end user "trusting" a "magic" CA, it's about what company
will tell you to use a CA, most of the time you don't have option as a
developer or even as a sysadmin since these kind of things are coming
strictly from InfoSec departments or are just some instruction to
accomplish some certification like ISO9001 or ISO27001, which for
isolated environments are required to be CA managed internally, and
must of the times the users may not see this CA, this will be actually
pushed by another external application installed in the company
workstation like CrowdStrike does, I'm not saying this will be the
case, but it's an example of how companies work now days with the CA's

> discussion, even if they're related.

Totally agree, now I'm thinking the same, it should be a feature
because there's more examples that I've been thinking about that may
require this to be even a bit more flexible, for example, when working
with edge computing, if you want (in the future because now it's not
possible, yet) authenticate a device against PostgreSQL it may require
to have that CA as a encoded string int he variable, not just as a
file, wild thought I know, but it may make sense 

> https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature

How can we work on that? because of the above it may be required to add
even more possibilities.

> name every time they run it?)

With that I was thinking more in the future than what you can do now,
the OAuth flow provides many features that can be implemented in the
future and I was just looking ahead with the CI example.

> I think that's reached critical mass, then.

More than happy to help with this!

--

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Sun, 14 Dec 2025 12:15:48 +0100

Hi!

> safety remains obvious to them. We can just focus on ergonomics for

I will for sure try to avoid this kind of format with comma separated
options, this mainly because are really hard to parse and manage in an
automated way, and sometimes, are hard to read when there's too many
options, and at some point, there could be many options since the flows
can start getting really complicated.
Why not keep something with debug levels? Even if it sounds really
classic, for parsing reasons are really good.

Now, if what is required it's counts or HTTP calls, probably this could
be like a "flow debug" an option like "PGOAUTHFLOWDEBUG" that depending
on the levels (info, debug, trace) can print from the hosts and/or url
calls, to the headers sent and received from the hosts.

The debug of a flow can be an entire set of levels due to the current
complexity and that may or may not increase in time, what do you think?

---

From: Jacob Champion <[email-masked]>
Date: Tue, 16 Dec 2025 10:48:18 -0800

On Fri, Dec 12, 2025 at 3:05 AM Zsolt Parragi <[email-masked]> wrote:
> (PGOAUTHDEBUG=UNSAFE:http...).

Thank you!

> about this, but I didn't see a better way without duplicating the

Yeah, I'm not entirely happy about it either. Let me think about some
alternatives... pgcommon is a possibility, as is reworking the API so
that it's more ephemeral (these probably don't need to be super
performant, so an `inline static` header implementation that reparses
the envvar each time might work).

> environment variables to psql?

1) Do you plan to be setting debug variables in production?
2) Do you want these settings to be part of a postgres:// URI?

For me the answer to both is "no", so I'm not too excited about adding
these as libpq connection parameters. Did you have another idea in
mind?

> noticing it,

I don't disagree. But at this point in these conversations, the
question posed is typically "is the new risk/reward tradeoff any worse
than PGSSLROOTCERT or PGSSLMODE or PGSERVICEFILE (or LD_LIBRARY_PATH
or PATH)?" I'd say no, not enough to introduce a new way of
configuring things for this particular setting.

I've argued in the other direction before [1], but I still feel good
about that, because I think a global keylogfile is more sensitive than
this.

> or without the application developer being aware of the
> possibility.

Mmm... I'd say that application developers always have to be aware of
user environment changes in the context of any Linux programming, let
alone libpq client development. The user is generally in partial
control of the linker. Nearly every libpq setting is accessible via
the environment. (setuid programming is its own specialized skillset
for a reason.)

Now, if there's any appetite to make the situation better, continuing
to add security-critical settings into the environment makes things
worse for anyone who wants to propose an alternative. But that's where
we stood as of the last related conversation I was involved in.

> But by splitting the setting into multiple flags,

Because it's not obviously spraying output all the time, you mean? We
could perhaps be noisier when any UNSAFE setting is in use.

> PGOAUTHDEBUG=UNSAFE:custom-ca=/path/to/the/file

I think I've been convinced by the existence of this thread that we
should split PGOAUTHCAFILE out of debug options entirely, pending the
resolution of some of the open questions.

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2BmY7zBXTqJT6EYP_6sdk7ro8L8ByToKb4f-hU5qnpOxhw%40mail.gmail.com

---

From: Jacob Champion <[email-masked]>
Date: Tue, 16 Dec 2025 11:16:41 -0800

On Sun, Dec 14, 2025 at 3:13 AM Jonathan Gonzalez V.
<[email-masked]> wrote:
> will tell you to use a CA

Sure, but my question isn't about the trust model. Just to confirm:
you're saying that it's common for enterprise provisioning apps
(CrowdStrike et al) to push CAs directly into a browser trust store,
but _not_ to the system trust paths?

> file, wild thought I know, but it may make sense

I think we want to keep these on disk; no reason to run up against
resource limits on the environment.

> How can we work on that? because of the above it may be required to add

Not sure what you mean. I think we're working on it now, in this thread?

On Sun, Dec 14, 2025 at 3:17 AM Jonathan Gonzalez V.
<[email-masked]> wrote:
> automated way

I feel _very_ strongly that the "debug" options are for people.
Specifically developers who are debugging. What use case do you have
for automation and parsing outside of libpq?

> and sometimes, are hard to read when there's too many

Can you explain more about what kinds of use cases would lead to
option explosion? When I'm developing I typically want to export an
interesting group of options once, and then not think about it for a
while. When debugging in production I typically want one particular
thing at a time.

> classic, for parsing reasons are really good.

I would say: because there's no natural order to the settings. It's a
bunch of on/off behaviors, some of which are safety-critical. What is
the "debug level" of disabling encryption compared to the debug level
of printing secrets or turning off parameter validation?

--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Wed, 17 Dec 2025 13:15:30 +0000

> configuring things for this particular setting.

Those are also bad, but there are also parameter alternatives for all of them.

> 2) Do you want these settings to be part of a postgres:// URI?

Not for debug settings, but if everyone agrees on splitting the CA
into its own setting, it could behave the same way as
sslrootcert/PGSSLROOTCERT.

> could perhaps be noisier when any UNSAFE setting is in use.

Yes, mainly that. And as you mentioned there's already existing
behavior like that in the code, so it's nothing new.

> alternatives...

I'll try these suggestions and see what they look like - and I'll
start a separate thread with it so that this thread can focus on the
CA variable.

> the environment. (setuid programming is its own specialized skillset

My concern is not somebody developing libpq directly on Linux, but
more complex situations.

For example:

1. there is libpq
2. libpq is used by scripting language bindings for python/ruby/etc
3. language libraries are used in ORM frameworks, which have their own
configuration interface
4. ORM frameworks are used in web frameworks / other libraries
5. those frameworks/libraries get used by somebody writing an actual
webpage/application
6. And that webpage/application gets installed/maintained by an
administrator/user, who might or might not be aware of this

And we also have Windows/other platforms, where environment variables
are less visible.

> worse for anyone who wants to propose an alternative

This is also probably a separate discussion, but what do you think
about introducing a parameter that disables environment variable
fallbacks? Both for existing variables like PGSSLROOTCERT and
new/debug variables like PGOAUTHCAFILE. (by default everything works
as currently; when specified environment variables are ignored)

---

From: Jacob Champion <[email-masked]>
Date: Thu, 18 Dec 2025 09:51:20 -0800

> Those are also bad, but there are also parameter alternatives for all of them.

But if the concern is security, the existence of the parameter
alternatives doesn't really seem to help you.

> sslrootcert/PGSSLROOTCERT.

I don't know if everyone does, but I've seen no pushback yet, so I
plan to do so (parameter + envvar).

I only nested it under debug settings because I thought there was no
production use case, and now that Jonathan is saying "yes, I have a
production case", that seems good enough. I don't think I need to
raise the bar any more than that.

> My concern is not somebody developing libpq directly on Linux, but

Understood (and I'd like to make this better too). But see below.

> as currently; when specified environment variables are ignored)

I like the idea of more application control over this, generally. I
think the concern that's been raised before, for example with the
superuser-can-do-too-much conversations, is: Piecemeal improvements,
without a consensus on the end goal, can paradoxically make things
less secure. Because now users have a harder time reasoning about the
system's behavior and designing for it. It's even worse if committers
can't reason about it and start working at cross purposes.

For example, if we lock down our envvars and then immediately farm
security-critical decisions out to Kerberos or Curl or PAM or etc.
which use their own envvars, in what cases is that better than telling
application developers that hey, you always need to be careful about
sanitizing your environment if you somehow don't trust it? I don't
really know (hand-wavy), and I think proposals would need to provide
good arguments in favor. Definitely a separate discussion.

Thanks,
--Jacob

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Sat, 20 Dec 2025 18:48:54 +0100

Hi!

> but _not_ to the system trust paths?

Yes! that use case it's more usual than one will expect, for example,
if you're routing different traffic for different apps into different
VPNs or routes, even between different browsers, this is also really
common now days because of the jailed-apps, something that in Linux
systems is pretty common, like snap, that create these "jailed"
environment so they can be supported across systems.

> resource limits on the environment.

No questions about it! was just an option that someone may come up
with! I've seen so many weird things that people does, specially on
shell scripts.

> Not sure what you mean. I think we're working on it now, in this
 
Yes, but having a list of ideas listed, that we all can read may make
sense, that's because following the threads with all the ideas at once
it's a big difficult some times!

> for automation and parsing outside of libpq?

Well, I have something to say about.
In my opinion, "debug" it's not just developers, helps a lot when
running and managing system, specially when using new technologies
(like this one specifically), helps to understand the flow and also to
realize what's going on and tune the configurations, this it's always
very useful when managing small or large systems.
On the other hand, since all the systems now days can run on hundreds
of servers or containers, no one looks into the logs manually, you have
automated system for it, that will read, parse, collect and distribute
your logs into different storage, databases(even PostgreSQL database
can be used for it) or display system. It is for theses cases that
having something that can be parsed is always useful. 

> while. When debugging in production I typically want one particular

Like an explicitly situations, I can imagine handling many different
environments to connect to and changing, not just OAuth config, but all
the configurations related to libpq on mixed different configurations,
even different authentication methods.

> of printing secrets or turning off parameter validation?

Well, I think I was misunderstood here, when I was talking about "debug
levels" I was talking about logs debug levels, now, disabling the
encryption, I'm guessing you mean HTTPS vs HTTP, if that's the case,
well, that should be controlled by the user when setting the endpoint,
I don't think it's something that should be controlled in another way
than just the endpoint protocol.

Now I'm confused about what we talk about when we write "debug level",
can you clarify what does it mean to you?

Regards!

---

From: Jacob Champion <[email-masked]>
Date: Mon, 5 Jan 2026 10:37:45 -0800

On Sat, Dec 20, 2025 at 9:53 AM Jonathan Gonzalez V.
> it's a big difficult some times!

See https://wiki.postgresql.org/wiki/Category:OAuth_Working_Group for
a current list of tagged [oauth] proposals. Or is that not what you're
asking about?

> In my opinion, "debug" it's not just developers, [...]
> since all the systems now days can run on hundreds

Sure, but that's not the use case for PGOAUTHDEBUG. It's fine to
develop a feature that handles production logging for client
authentication details -- it's just emphatically not what that envvar
was designed to do. This is a developer feature which turns out to be
hiding another feature that people want to use in production today.

I know the most visible aspect of PGOAUTHDEBUG=UNSAFE is the logging
spray, so that might have contributed to the confusion.

> levels" I was talking about logs debug levels

Right, and I'm not. I guess that's the main disconnect here: I'm only
talking about enabling and disabling the features exposed by
PGOAUTHDEBUG. I don't think a debug level helps with that, which is
why I proposed a bitmap.

But that's a feature for a different thread name. I think we should
continue this one by adding an oauth_ca_file connection parameter and
documentation, including the default behavior (which defers to Curl).

--Jacob

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Tue, 06 Jan 2026 09:40:20 +0100

Hi!

> a current list of tagged [oauth] proposals. Or is that not what

Not specifically, but that will work more than fine for sure! Thank
you!

> documentation, including the default behavior (which defers to Curl).

Ok, promoting this to something external to the debug makes a lot of
sense to me, that will help a lot to increase the possible usage of
this parameter.

I will for sure still allow an environment variable too like OAUTH_CA
or OAUTH_CA_FILE, just because environment variable for these
parameters is widely used, just like in curl[1] has cacert_file and
support for CURL_CA_BUNDLE, both options make sure that users may not
be limited.

I already worked a patch (before this one) to add an option to pass the
CA but I discarded that because I didn't thought it was going to be
accepted, I can rework that with all the ideas, but, what do you think
about creating a wiki page with all the ideas to manage the
certificates? probably the CA will require to also add some skip or
insecure options, full bundles and how to build them, etc.

Regards!

[1] https://curl.se/docs/sslcerts.html
-- 
Jonathan Gonzalez V. <[email-masked]>
EnterpriseDB

---

From: Jacob Champion <[email-masked]>
Date: Tue, 6 Jan 2026 08:28:39 -0800

On Tue, Jan 6, 2026 at 12:45 AM Jonathan Gonzalez V.
> support for CURL_CA_BUNDLE, both options make sure that users may not

Right -- I hadn't meant that you should remove the PGOAUTHCAFILE
envvar from your patch, just that an oauth_ca_file parameter should be
added as well.

> certificates?

You're more than welcome to add any wiki pages you think would be
useful -- you certainly don't need my permission :D

If you don't have edit access yet, see

    https://wiki.postgresql.org/wiki/WikiEditing

> probably the CA will require to also add some skip or

I'm not quite sure what you mean by these, but it might be easier to
read the wiki page you had in mind and comment on that.

Thanks!
--Jacob

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Tue, 17 Feb 2026 18:18:16 +0100

Hello!

> envvar from your patch, just that an oauth_ca_file parameter should

I'm attached a v2 of this patch I'm not really sure if this is what you
mean.

I want to add some test for this option that I think it could be really
useful, what do you think?

-- 
Jonathan Gonzalez V. <[email-masked]>
From ed6b0146d45ded6f0970f9bb8eb9a34d78960f2d Mon Sep 17 00:00:00 2001
From: "Jonathan Gonzalez V." <[email-masked]>
Date: Wed, 29 Oct 2025 16:54:42 +0100
Subject: [PATCH v2 1/1] libpq-oauth: allow changing the CA when not in debug
 mode

Signed-off-by: Jonathan Gonzalez V. <[email-masked]>
---
 doc/src/sgml/libpq.sgml                  | 23 ++++++++++++++++------
 src/interfaces/libpq-oauth/oauth-curl.c  | 25 ++++++++++--------------
 src/interfaces/libpq-oauth/oauth-utils.c |  3 +++
 src/interfaces/libpq-oauth/oauth-utils.h |  2 ++
 src/interfaces/libpq/fe-auth-oauth.c     |  3 +++
 src/interfaces/libpq/fe-connect.c        |  4 ++++
 src/interfaces/libpq/libpq-int.h         |  1 +
 src/tools/pgindent/typedefs.list         |  1 +
 8 files changed, 41 insertions(+), 21 deletions(-)

index 21e1ba34a4e..f28871d402a 100644
@@ -10519,12 +10519,6 @@ typedef struct PGoauthBearerRequest
@@ -10546,6 +10540,23 @@ typedef struct PGoauthBearerRequest

diff --git a/src/interfaces/libpq-oauth/oauth-curl.c b/src/interfaces/libpq-oauth/oauth-curl.c
index 691e7ec1d9f..0460cce65bb 100644
--- a/src/interfaces/libpq-oauth/oauth-curl.c
+++ b/src/interfaces/libpq-oauth/oauth-curl.c
@@ -56,6 +56,7 @@
 #define conn_oauth_discovery_uri(CONN) (CONN->oauth_discovery_uri)
 #define conn_oauth_issuer_id(CONN) (CONN->oauth_issuer_id)
 #define conn_oauth_scope(CONN) (CONN->oauth_scope)
+#define conn_oauth_ca_file(CONN) (CONN->oauth_ca_file)
 #define conn_sasl_state(CONN) (CONN->sasl_state)
 
 #define set_conn_altsock(CONN, VAL) do { CONN->altsock = VAL; } while (0)
@@ -1708,8 +1709,10 @@ debug_callback(CURL *handle, curl_infotype type, char *data, size_t size,
  * start_request().
  */
 static bool
-setup_curl_handles(struct async_ctx *actx)
+setup_curl_handles(struct async_ctx *actx, PGconn *conn)
 {
+	const char *ca_path = conn_oauth_ca_file(conn);
+
 	/*
 	 * Create our multi handle. This encapsulates the entire conversation with
 	 * libcurl for this connection.
@@ -1798,20 +1801,12 @@ setup_curl_handles(struct async_ctx *actx)
 	}
 
 	/*
-	 * If we're in debug mode, allow the developer to change the trusted CA
-	 * list. For now, this is not something we expose outside of the UNSAFE
-	 * mode, because it's not clear that it's useful in production: both libpq
-	 * and the user's browser must trust the same authorization servers for
-	 * the flow to work at all, so any changes to the roots are likely to be
-	 * done system-wide.
+	 * Allow to set the CA even if we're not in debug mode, this would make it easy
+	 * to work on environments were the CA could be internal and available on every
+	 * system, like big companies with airgap systems.
 	 */
-	if (actx->debugging)
-	{
-		const char *env;
-
-		if ((env = getenv("PGOAUTHCAFILE")) != NULL)
-			CHECK_SETOPT(actx, CURLOPT_CAINFO, env, return false);
-	}
+	if (ca_path != NULL)
+		CHECK_SETOPT(actx, CURLOPT_CAINFO, ca_path, return false);
 
 	/*
 	 * Suppress the Accept header to make our request as minimal as possible.
@@ -2804,7 +2799,7 @@ pg_fe_run_oauth_flow_impl(PGconn *conn)
 		if (!setup_multiplexer(actx))
 			goto error_return;
 
-		if (!setup_curl_handles(actx))
+		if (!setup_curl_handles(actx, conn))
 			goto error_return;
 	}
 
diff --git a/src/interfaces/libpq-oauth/oauth-utils.c b/src/interfaces/libpq-oauth/oauth-utils.c
index 4ebe7d0948c..52a8599e15d 100644
--- a/src/interfaces/libpq-oauth/oauth-utils.c
+++ b/src/interfaces/libpq-oauth/oauth-utils.c
@@ -41,6 +41,7 @@ conn_oauth_client_secret_func conn_oauth_client_secret;
 conn_oauth_discovery_uri_func conn_oauth_discovery_uri;
 conn_oauth_issuer_id_func conn_oauth_issuer_id;
 conn_oauth_scope_func conn_oauth_scope;
+conn_oauth_ca_file_func conn_oauth_ca_file;
 conn_sasl_state_func conn_sasl_state;
 
 set_conn_altsock_func set_conn_altsock;
@@ -70,6 +71,7 @@ libpq_oauth_init(pgthreadlock_t threadlock_impl,
 				 conn_oauth_discovery_uri_func discoveryuri_impl,
 				 conn_oauth_issuer_id_func issuerid_impl,
 				 conn_oauth_scope_func scope_impl,
+				 conn_oauth_ca_file_func cafile_impl,
 				 conn_sasl_state_func saslstate_impl,
 				 set_conn_altsock_func setaltsock_impl,
 				 set_conn_oauth_token_func settoken_impl)
@@ -82,6 +84,7 @@ libpq_oauth_init(pgthreadlock_t threadlock_impl,
 	conn_oauth_discovery_uri = discoveryuri_impl;
 	conn_oauth_issuer_id = issuerid_impl;
 	conn_oauth_scope = scope_impl;
+	conn_oauth_ca_file = cafile_impl;
 	conn_sasl_state = saslstate_impl;
 	set_conn_altsock = setaltsock_impl;
 	set_conn_oauth_token = settoken_impl;
diff --git a/src/interfaces/libpq-oauth/oauth-utils.h b/src/interfaces/libpq-oauth/oauth-utils.h
index 9f4d5b692d2..22183f21c6a 100644
--- a/src/interfaces/libpq-oauth/oauth-utils.h
+++ b/src/interfaces/libpq-oauth/oauth-utils.h
@@ -40,6 +40,7 @@ DECLARE_GETTER(char *, oauth_client_secret);
 DECLARE_GETTER(char *, oauth_discovery_uri);
 DECLARE_GETTER(char *, oauth_issuer_id);
 DECLARE_GETTER(char *, oauth_scope);
+DECLARE_GETTER(char *, oauth_ca_file);
 DECLARE_GETTER(fe_oauth_state *, sasl_state);
 
 DECLARE_SETTER(pgsocket, altsock);
@@ -59,6 +60,7 @@ extern PGDLLEXPORT void libpq_oauth_init(pgthreadlock_t threadlock,
 										 conn_oauth_discovery_uri_func discoveryuri_impl,
 										 conn_oauth_issuer_id_func issuerid_impl,
 										 conn_oauth_scope_func scope_impl,
+										 conn_oauth_ca_file_func cafile_impl,
 										 conn_sasl_state_func saslstate_impl,
 										 set_conn_altsock_func setaltsock_impl,
 										 set_conn_oauth_token_func settoken_impl);
diff --git a/src/interfaces/libpq/fe-auth-oauth.c b/src/interfaces/libpq/fe-auth-oauth.c
index 67879d64b39..74fa737e5d3 100644
--- a/src/interfaces/libpq/fe-auth-oauth.c
+++ b/src/interfaces/libpq/fe-auth-oauth.c
@@ -816,6 +816,7 @@ DEFINE_GETTER(char *, oauth_client_secret);
 DEFINE_GETTER(char *, oauth_discovery_uri);
 DEFINE_GETTER(char *, oauth_issuer_id);
 DEFINE_GETTER(char *, oauth_scope);
+DEFINE_GETTER(char *, oauth_ca_file);
 DEFINE_GETTER(fe_oauth_state *, sasl_state);
 
 DEFINE_SETTER(pgsocket, altsock);
@@ -845,6 +846,7 @@ use_builtin_flow(PGconn *conn, fe_oauth_state *state)
 						 conn_oauth_discovery_uri_func discoveryuri_impl,
 						 conn_oauth_issuer_id_func issuerid_impl,
 						 conn_oauth_scope_func scope_impl,
+						 conn_oauth_ca_file_func cafile_impl,
 						 conn_sasl_state_func saslstate_impl,
 						 set_conn_altsock_func setaltsock_impl,
 						 set_conn_oauth_token_func settoken_impl);
@@ -932,6 +934,7 @@ use_builtin_flow(PGconn *conn, fe_oauth_state *state)
 			 conn_oauth_discovery_uri,
 			 conn_oauth_issuer_id,
 			 conn_oauth_scope,
+			 conn_oauth_ca_file,
 			 conn_sasl_state,
 			 set_conn_altsock,
 			 set_conn_oauth_token);
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index a0d2f749811..6f5a1006206 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -412,6 +412,10 @@ static const internalPQconninfoOption PQconninfoOptions[] = {
 		"OAuth-Scope", "", 15,
 	offsetof(struct pg_conn, oauth_scope)},
 
+	{"oauth_ca_file", "PGOAUTHCAFILE", NULL, NULL,
+	 "Oauth-CA-File", "", 64,
+	 offsetof(struct pg_conn, oauth_ca_file)},
+
 	{"sslkeylogfile", NULL, NULL, NULL,
 		"SSL-Key-Log-File", "D", 64,
 	offsetof(struct pg_conn, sslkeylogfile)},
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index fb6a7cbf15d..3f799e9b34d 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -444,6 +444,7 @@ struct pg_conn
 	char	   *oauth_client_secret;	/* client secret */
 	char	   *oauth_scope;	/* access token scope */
 	char	   *oauth_token;	/* access token */
+	char       *oauth_ca_file;	/* CA file path  */
 	bool		oauth_want_retry;	/* should we retry on failure? */
 
 	/* Optional file to write trace info to */
diff --git a/src/tools/pgindent/typedefs.list b/src/tools/pgindent/typedefs.list
index 241945734ec..e09858263e7 100644
--- a/src/tools/pgindent/typedefs.list
+++ b/src/tools/pgindent/typedefs.list
@@ -3587,6 +3587,7 @@ conn_oauth_client_secret_func
 conn_oauth_discovery_uri_func
 conn_oauth_issuer_id_func
 conn_oauth_scope_func
+conn_oauth_ca_file_func
 conn_sasl_state_func
 contain_aggs_of_level_context
 contain_placeholder_references_context
-- 
2.51.0

---

From: Jacob Champion <[email-masked]>
Date: Wed, 18 Feb 2026 16:46:48 -0800

On Tue, Feb 17, 2026 at 9:23 AM Jonathan Gonzalez V.
> I'm attached a v2 of this patch I'm not really sure if this is what you

At a glance, I think so!

> +#define conn_oauth_ca_file(CONN) (CONN->oauth_ca_file)

Arrrghh I hadn't even considered that this thread would conflict with
the changes over at [1]. Well, the silver lining is that I already
know I have to get most of that work in; this just serializes things.

> useful, what do you think?

Definitely. I could see either upgrading the oauth_validator test
suite to use HTTPS throughout, and then setting the new envvar
globally, or just adding a single test that switches it on (but I'm
not sure that's actually less work, since you have to teach
oauth_server.py to speak HTTPS either way).

Thanks!
--Jacob

[1] https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Thu, 19 Feb 2026 15:18:34 +0100

Hi!

> know I have to get most of that work in; this just serializes things.

Well, it will definitely conflict but I can rebase the work on that
patch, not an issue, since now I understand what you mean it's even
more fun! What do you think? I can do some testing and review on those
patches too while working on a rebase, so I think it's a win-win

> oauth_server.py to speak HTTPS either way).

Ok, so probably a new patch to teach oauth_server.py to speak HTTPS
could be good? Since it requires to create certificates and lot of
testing work a different patch could be better right? just to add HTTPS
support.

Thank you!

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 19 Feb 2026 15:22:52 +0100

> On 19 Feb 2026, at 15:18, Jonathan Gonzalez V. <[email-masked]> wrote:

> testing work a different patch could be better right? just to add HTTPS

+1, that work should be considered on its own as it has value independent of
the rest of this patchset.

--
Daniel Gustafsson

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Mon, 09 Mar 2026 20:59:45 +0100

Hello!

Since the requested work [1] about adding the test has already been
merged, I'm attaching the updated version of the patch with the proper
test for the options.

I may need to change the patch a lot after the ABI stabilization
patches are merged, but this helps to keep the patch in good shape.

Regards!

[1]
https://www.postgresql.org/message-id/flat/8a296a2c128aba924bff0ae48af2b88bf8f9188d.camel%40gmail.com

-- 
Jonathan Gonzalez V. 
EDB: https://www.enterprisedb.com
From e477c6ed6f6fd71d5d8cd74f0b89df3e53571f76 Mon Sep 17 00:00:00 2001
From: "Jonathan Gonzalez V." <[email-masked]>
Date: Wed, 29 Oct 2025 16:54:42 +0100
Subject: [PATCH v3 1/1] libpq-oauth: allow changing the CA when not in debug
 mode

Signed-off-by: Jonathan Gonzalez V. <[email-masked]>
---
 doc/src/sgml/libpq.sgml                       | 23 ++++++++---
 src/interfaces/libpq-oauth/oauth-curl.c       | 25 +++++-------
 src/interfaces/libpq-oauth/oauth-utils.c      |  3 ++
 src/interfaces/libpq-oauth/oauth-utils.h      |  2 +
 src/interfaces/libpq/fe-auth-oauth.c          |  3 ++
 src/interfaces/libpq/fe-connect.c             |  4 ++
 src/interfaces/libpq/libpq-int.h              |  1 +
 .../modules/oauth_validator/t/001_server.pl   | 40 ++++++++++++++++++-
 .../modules/oauth_validator/t/OAuth/Server.pm |  2 +-
 src/tools/pgindent/typedefs.list              |  1 +
 10 files changed, 80 insertions(+), 24 deletions(-)

index 6db823808fc..24fda826dd1 100644
@@ -10620,12 +10620,6 @@ typedef struct
@@ -10647,6 +10641,23 @@ typedef struct

index 2c147f98d0d..11145daa451 100644
 
 #define set_conn_altsock(CONN, VAL) do { CONN->altsock = VAL; } while (0)
@@ -1706,8 +1707,10 @@ debug_callback(CURL *handle, curl_infotype type, char *data, size_t size,
  * start_request().
  */
 static bool
-setup_curl_handles(struct async_ctx *actx)
+setup_curl_handles(struct async_ctx *actx, PGconn *conn)
 {
+	const char *ca_path = conn_oauth_ca_file(conn);
+
 	/*
 	 * Create our multi handle. This encapsulates the entire conversation with
 	 * libcurl for this connection.
@@ -1796,20 +1799,12 @@ setup_curl_handles(struct async_ctx *actx)
 	}
 
 	/*
 
 	/*
 	 * Suppress the Accept header to make our request as minimal as possible.
@@ -2802,7 +2797,7 @@ pg_fe_run_oauth_flow_impl(PGconn *conn)
 		if (!setup_multiplexer(actx))
 			goto error_return;

 
 
index 2aef327c68b..4f09f1930e8 100644
@@ -839,6 +839,7 @@ DEFINE_GETTER(char *, oauth_client_secret);
 
 DEFINE_SETTER(pgsocket, altsock);
@@ -868,6 +869,7 @@ use_builtin_flow(PGconn *conn, fe_oauth_state *state)
 						 conn_oauth_discovery_uri_func discoveryuri_impl,
 						 conn_oauth_issuer_id_func issuerid_impl,
 						 conn_oauth_scope_func scope_impl,
+						 conn_oauth_ca_file_func cafile_impl,
 						 conn_sasl_state_func saslstate_impl,
 						 set_conn_altsock_func setaltsock_impl,
 						 set_conn_oauth_token_func settoken_impl);
@@ -955,6 +957,7 @@ use_builtin_flow(PGconn *conn, fe_oauth_state *state)
 			 conn_oauth_discovery_uri,
 			 conn_oauth_issuer_id,
 			 conn_oauth_scope,
+			 conn_oauth_ca_file,
 			 conn_sasl_state,
 			 set_conn_altsock,
 			 set_conn_oauth_token);
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index db9b4c8edbf..9a5452966dc 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -413,6 +413,10 @@ static const internalPQconninfoOption PQconninfoOptions[] = {
 		"OAuth-Scope", "", 15,
 	offsetof(struct pg_conn, oauth_scope)},
 
index bd7eb59f5f8..1f1fb89e02f 100644
 
 	/* Optional file to write trace info to */
diff --git a/src/test/modules/oauth_validator/t/001_server.pl b/src/test/modules/oauth_validator/t/001_server.pl
index cdad2ae8011..b66d99dd4bb 100644
--- a/src/test/modules/oauth_validator/t/001_server.pl
+++ b/src/test/modules/oauth_validator/t/001_server.pl
@@ -137,10 +137,46 @@ $node->connect_fails(
 	expected_stderr =>
 	  qr/failed to fetch OpenID discovery document:.*peer certificate/i);
 
-# Now we can use our alternative CA.
-$ENV{PGOAUTHCAFILE} = "$ENV{cert_dir}/root+server_ca.crt";
+# Make sure that PGOAUTHDEBUG is not required to specify the certificate
+delete $ENV{PGOAUTHDEBUG};
 
+# The alternative CA path to use during the tests
+my $alternative_ca = "$ENV{cert_dir}/root+server_ca.crt";
+
+# Make sure we can use oauth_ca_file option to specify the alternative CA path
 my $user = "test";
+$node->connect_ok(
+	"user=$user dbname=postgres oauth_issuer=$issuer oauth_client_id=f02c6361-0635 oauth_ca_file=$alternative_ca",
+	"connect as test",
+	expected_stderr =>
+	  qr@Visit https://example\.com/ and enter the code: postgresuser@,
+	log_like => [
+		qr/oauth_validator: token="9243959234", role="$user"/,
+		qr/oauth_validator: issuer="\Q$issuer\E", scope="openid postgres"/,
+		qr/connection authenticated: identity="test" method=oauth/,
+		qr/connection authorized/,
+	]);
+
+# Make sure that we can use the environment variable without the PGOAUTHDEBUG
+# and use it for the rest of the tests
+$ENV{PGOAUTHCAFILE} = $alternative_ca;
+
+$node->connect_ok(
+	"user=$user dbname=postgres oauth_issuer=$issuer oauth_client_id=f02c6361-0635",
+	"connect as test",
+	expected_stderr =>
+	  qr@Visit https://example\.com/ and enter the code: postgresuser@,
+	log_like => [
+		qr/oauth_validator: token="9243959234", role="$user"/,
+		qr/oauth_validator: issuer="\Q$issuer\E", scope="openid postgres"/,
+		qr/connection authenticated: identity="test" method=oauth/,
+		qr/connection authorized/,
+	]);
+
+# Enable PGOAUTHDEBUG=UNSAFE to have the proper count later with the `[libpq] total number of polls` messages
+$ENV{PGOAUTHDEBUG} = "UNSAFE";
+
+$user = "test";
 $node->connect_ok(
 	"user=$user dbname=postgres oauth_issuer=$issuer oauth_client_id=f02c6361-0635",
 	"connect as test",
diff --git a/src/test/modules/oauth_validator/t/OAuth/Server.pm b/src/test/modules/oauth_validator/t/OAuth/Server.pm
index d923d4c5eb2..62a29c283df 100644
--- a/src/test/modules/oauth_validator/t/OAuth/Server.pm
+++ b/src/test/modules/oauth_validator/t/OAuth/Server.pm
@@ -28,7 +28,7 @@ daemon implemented in t/oauth_server.py. (Python has a fairly usable HTTP server
 in its standard library, so the implementation was ported from Perl.)
 
 This authorization server serves HTTPS on 127.0.0.1 (IPv4 only). libpq will need
-to set PGOAUTHDEBUG=UNSAFE and PGOAUTHCAFILE with the right CA.
+to set PGOAUTHCAFILE with the right CA.
 
 =cut
 
diff --git a/src/tools/pgindent/typedefs.list b/src/tools/pgindent/typedefs.list
index 3250564d4ff..c5795e7e868 100644
--- a/src/tools/pgindent/typedefs.list
+++ b/src/tools/pgindent/typedefs.list
@@ -3590,6 +3590,7 @@ conn_oauth_client_secret_func
 conn_oauth_discovery_uri_func
 conn_oauth_issuer_id_func
 conn_oauth_scope_func
+conn_oauth_ca_file_func
 conn_sasl_state_func
 contain_aggs_of_level_context
 contain_placeholder_references_context
-- 
2.51.0

---

From: Jacob Champion <[email-masked]>
Date: Tue, 10 Mar 2026 09:43:27 -0700

On Mon, Mar 9, 2026 at 1:04 PM Jonathan Gonzalez V.
> patches are merged, but this helps to keep the patch in good shape.

Thanks! For a head start, consider locally rebasing over v7-0002 from
this thread:

    https://postgr.es/m/CAOYmi%2B%3DPr7AAdkcKXyLw3ycxcrjGKsOV2CTYVV2PKYQw9ecG0Q%40mail.gmail.com

I don't think there will be much rebase pain (or at least, I hope
not); take a look at the handling of `actx->client_id` in v7-0001 for
an example.

--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Tue, 10 Mar 2026 22:40:48 +0000

Hello

I only have a few minor comments/questions:

Shouldn't we free oauth_ca_file in freePGconn?

Would a test case with an invalid/incorrect CA file be also useful, or
is that too much testing of curl internals?

Shouldn't the doc update also include oauth_ca_file?

+ {"oauth_ca_file", "PGOAUTHCAFILE", NULL, NULL,
+ "Oauth-CA-File", "", 64,
+ offsetof(struct pg_conn, oauth_ca_file)}

That should be OAuth-CA-File

where the CA

---

From: Zsolt Parragi <[email-masked]>
Date: Tue, 17 Mar 2026 06:41:25 +0000

Hello

These variables are still not freed, I am missing something why it
isn't required?

Shouldn't we free this in freePGconn?

+ char    *ca_file; /* oauth_ca_file */

Similarly with free_async_ctx?

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Tue, 17 Mar 2026 22:37:39 +0100

Hello!!

> Similarly with free_async_ctx?

I totally miss this comments, and I had it noted

Attaching v5

-- 
Jonathan Gonzalez V. 
EDB: https://www.enterprisedb.com
From a27875e770b9f74481cf839b168ea187e040d279 Mon Sep 17 00:00:00 2001
From: "Jonathan Gonzalez V." <[email-masked]>
Date: Wed, 29 Oct 2025 16:54:42 +0100
Subject: [PATCH v5 1/1] libpq-oauth: allow changing the CA when not in debug
 mode

Reviewed-by: Zsolt Parragi <zsolt,[email-masked]>
Signed-off-by: Jonathan Gonzalez V. <[email-masked]>
---
 doc/src/sgml/libpq.sgml                       | 23 ++++++++---
 src/interfaces/libpq-oauth/oauth-curl.c       | 27 +++++++------
 src/interfaces/libpq/fe-connect.c             |  5 +++
 src/interfaces/libpq/libpq-int.h              |  1 +
 .../modules/oauth_validator/t/001_server.pl   | 40 ++++++++++++++++++-
 .../modules/oauth_validator/t/OAuth/Server.pm |  2 +-
 6 files changed, 76 insertions(+), 22 deletions(-)

diff --git a/src/interfaces/libpq-oauth/oauth-curl.c b/src/interfaces/libpq-oauth/oauth-curl.c
index 052ecd32da2..561875d6db1 100644
--- a/src/interfaces/libpq-oauth/oauth-curl.c
+++ b/src/interfaces/libpq-oauth/oauth-curl.c
@@ -17,6 +17,7 @@
 
 #include <curl/curl.h>
 #include <math.h>
+#include <string.h>
 #include <unistd.h>
 
 #if defined(HAVE_SYS_EPOLL_H)
@@ -216,6 +217,7 @@ struct async_ctx
 	/* relevant connection options cached from the PGconn */
 	char	   *client_id;		/* oauth_client_id */
 	char	   *client_secret;	/* oauth_client_secret (may be NULL) */
+	char	   *ca_file;		/* oauth_ca_file */
 
 	/* options cached from the PGoauthBearerRequest (we don't own these) */
 	const char *discovery_uri;
@@ -336,6 +338,7 @@ free_async_ctx(struct async_ctx *actx)
 
 	free(actx->client_id);
 	free(actx->client_secret);
+	free(actx->ca_file);
 
 	free(actx);
 }
@@ -1834,20 +1837,12 @@ setup_curl_handles(struct async_ctx *actx)
 	}
 
 	/*
-	 * If we're in debug mode, allow the developer to change the trusted CA
-	 * list. For now, this is not something we expose outside of the UNSAFE
-	 * mode, because it's not clear that it's useful in production: both libpq
-	 * and the user's browser must trust the same authorization servers for
-	 * the flow to work at all, so any changes to the roots are likely to be
-	 * done system-wide.
+	 * Allow to set the CA even if we're not in debug mode, this would make it
+	 * easy to work on environments where the CA could be internal and
+	 * available on every system, like big companies with airgap systems.
 	 */
-	if (actx->debugging)
-	{
-		const char *env;
-
-		if ((env = getenv("PGOAUTHCAFILE")) != NULL)
-			CHECK_SETOPT(actx, CURLOPT_CAINFO, env, return false);
-	}
+	if (actx->ca_file != NULL)
+		CHECK_SETOPT(actx, CURLOPT_CAINFO, actx->ca_file, return false);
 
 	/*
 	 * Suppress the Accept header to make our request as minimal as possible.
@@ -3125,6 +3120,12 @@ pg_start_oauthbearer(PGconn *conn, PGoauthBearerRequestV2 *request)
 			if (!actx->client_secret)
 				goto oom;
 		}
+		else if (strcmp(opt->keyword, "oauth_ca_file") == 0)
+		{
+			actx->ca_file = strdup(opt->val);
+			if (!actx->ca_file)
+				goto oom;
+		}
 	}
 
 	PQconninfoFree(conninfo);
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index db9b4c8edbf..4f3af722881 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -413,6 +413,10 @@ static const internalPQconninfoOption PQconninfoOptions[] = {
 		"OAuth-Scope", "", 15,
 	offsetof(struct pg_conn, oauth_scope)},
 
+	{"oauth_ca_file", "PGOAUTHCAFILE", NULL, NULL,
+	 "OAuth-CA-File", "", 64,
+	 offsetof(struct pg_conn, oauth_ca_file)},
+
 	{"sslkeylogfile", NULL, NULL, NULL,
 		"SSL-Key-Log-File", "D", 64,
 	offsetof(struct pg_conn, sslkeylogfile)},
@@ -5158,6 +5162,7 @@ freePGconn(PGconn *conn)
 	free(conn->oauth_discovery_uri);
 	free(conn->oauth_client_id);
 	free(conn->oauth_client_secret);
+	free(conn->oauth_ca_file);
 	free(conn->oauth_scope);
 	/* Note that conn->Pfdebug is not ours to close or free */
 	free(conn->events);
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index bd7eb59f5f8..1f1fb89e02f 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -444,6 +444,7 @@ struct pg_conn
 	char	   *oauth_client_secret;	/* client secret */
 	char	   *oauth_scope;	/* access token scope */
 	char	   *oauth_token;	/* access token */
+	char       *oauth_ca_file;	/* CA file path  */
 	bool		oauth_want_retry;	/* should we retry on failure? */

 

 =cut
 
-- 
2.51.0

---

From: Zsolt Parragi <[email-masked]>
Date: Thu, 19 Mar 2026 20:15:28 +0000

Thanks, v5 looks good!

(One documentation comment I missed previously: the oauth_ca_file
connection parameter should also be documented, but that's just the
same documentation repeated at one more place)

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Fri, 20 Mar 2026 21:17:21 +0100

Hello!
> same documentation repeated at one more place)

Good point! attached with the new doc and updated reviewers list (sorry
Jacob I forgot you the first time)

Regards!

-- 
Jonathan Gonzalez V. 
EDB: https://www.enterprisedb.com
From 32f3f1163a061c3a512e05dfe55e7c643e73fcf8 Mon Sep 17 00:00:00 2001
From: "Jonathan Gonzalez V." <[email-masked]>
Date: Wed, 29 Oct 2025 16:54:42 +0100
Subject: [PATCH v6 1/1] libpq-oauth: allow changing the CA when not in debug
 mode

Reviewed-by: Jacob Champion <[email-masked]>
Reviewed-by: Zsolt Parragi <[email-masked]>
Signed-off-by: Jonathan Gonzalez V. <[email-masked]>
---
 doc/src/sgml/libpq.sgml                       | 33 ++++++++++++---
 src/interfaces/libpq-oauth/oauth-curl.c       | 27 +++++++------
 src/interfaces/libpq/fe-connect.c             |  5 +++
 src/interfaces/libpq/libpq-int.h              |  1 +
 .../modules/oauth_validator/t/001_server.pl   | 40 ++++++++++++++++++-
 .../modules/oauth_validator/t/OAuth/Server.pm |  2 +-
 6 files changed, 86 insertions(+), 22 deletions(-)

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 6db823808fc..cb836abc978 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -2585,6 +2585,16 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
       </listitem>
      </varlistentry>
 
+     <varlistentry id="libpq-connect-oauth-ca-file" xreflabel="oauth_ca_file">
+      <term><literal>oauth_ca_file</literal></term>
+      <listitem>
+       <para>
+        Allows to specify the path to a CA file that will be used by the client
+        to verify the certificate from the OAuth server side.
+       </para>
+      </listitem>
+     </varlistentry>
+
     </variablelist>
    </para>
   </sect2>
@@ -10620,12 +10630,6 @@ typedef struct
        permits the use of unencrypted HTTP during the OAuth provider exchange
       </para>
      </listitem>
-     <listitem>
-      <para>
-       allows the system's trusted CA list to be completely replaced using the
-       <envar>PGOAUTHCAFILE</envar> environment variable
-      </para>
-     </listitem>
      <listitem>
       <para>
        prints HTTP traffic (containing several critical secrets) to standard
@@ -10647,6 +10651,23 @@ typedef struct
     </para>
    </warning>
   </sect2>
+  <sect2 id="libpq-oauth-environment">
+   <title>Environment variables</title>
+   <para>
+    The behavior of the OAuth calls may be affected by the following variables:
+    <variablelist>
+     <varlistentry>
+      <term><envar>PGOAUTHCAFILE</envar></term>
+      <listitem>
+       <para>
+        Allows to specify the path to a CA file that will be used by the client
+        to verify the certificate from the OAuth server side.
+       </para>
+      </listitem>
+     </varlistentry>
+    </variablelist>
+   </para>
+  </sect2>
  </sect1>

 #include <curl/curl.h>
 #include <math.h>
+#include <string.h>
 #include <unistd.h>

 
 	free(actx->client_id);
 
 	free(actx);
 }
 
 	/*
 
 	/*

 

 
 
 =cut
 
-- 
2.51.0

---

From: Jacob Champion <[email-masked]>
Date: Mon, 30 Mar 2026 14:33:29 -0700

On Fri, Mar 20, 2026 at 1:17 PM Jonathan Gonzalez V.
> Jacob I forgot you the first time)

No worries -- I think most committers add themselves as they see fit.

This is now committed; thank you! I did munge the documentation and
comments to better match (IMHO) current style, and I reorganized the
new tests a bit. Some additional refactoring will be needed in
001_server soon, I think.

Now off to rebase the PGOAUTHDEBUG patch...

--Jacob