Обсуждение: tlsv1 alert iso-8859-1 ca error on cert authentication

Steps to reproduce:

1. Install Postgres 17.5 and OpenSsl on Windows 11

2. Run the following commands. Enter `postgres` as common name on client cert creation:

   ```sh
   openssl req -new -x509 -days 365 -nodes -out server.crt -keyout server.key
   openssl req -new -nodes -out client.csr -keyout client.key
   openssl x509 -req -in client.csr -CA server.crt -CAkey server.key -CAcreateserial -out client.crt -days 365
    ```

3. Copy files to server data directory:

    ```sh
    copy server.key "C:\Program Files\PostgreSQL\17\data"
    copy server.crt "C:\Program Files\PostgreSQL\17\data\root.crt"
    copy server.crt "C:\Program Files\PostgreSQL\17\data"

4. Add the following lines to top of `pg_hba.conf`:

       hostssl all postgres ::1/0 cert
       hostssl all postgres 0.0.0.0/0 cert

5. Add the following lines to end of `postgresql.conf`:

       ssl = on
       ssl_ca_file = 'root.crt'
       ssl_cert_file = 'server.crt'
       ssl_key_file = 'server.key'

6. Re-start postgres service

7. Run commands

    ```sh
    set PGSSLCERT=client.crt
    set PGSSLKEY=client.key
    "C:\Program Files\PostgreSQL\17\bin\pg_dump" -f "test.backup" -F c -h localhost -U postgres postgres

 
Observed:

> pg_dump: error: connection to server at "localhost" (::1), port 5432
> failed: SSL error: tlsv1 alert unknown ca

Postgres log contains:

> [unknown] ::1 [unknown] LOG:  could not accept SSL connection:
> certificate verify failed [unknown] ::1 [unknown] DETAIL:  Client
> certificate verification failed at depth 0: self-signed certificate.
>     Failed certificate data (unverified): subject
> "...rju/L=test/O=test/CN=postgres/emailAddress=test@example.com",
> serial number 14465968192346824308, issuer
> "...rju/L=test/O=test/CN=postgres/emailAddress=test@example.com"

Reported also in

https://stackoverflow.com/questions/79657806/why-postgres-17-cert-authentication-fails-in-windows

Andrus.

Andrus <kobruleht2@hot.ee> writes:
> Observed:

>>> pg_dump: error: connection to server at "localhost" (::1), port 5432
>>> failed: SSL error: tlsv1 alert unknown ca

> Postgres log contains:

>>> [unknown] ::1 [unknown] LOG:  could not accept SSL connection:
>>> certificate verify failed [unknown] ::1 [unknown] DETAIL: Client
>>> certificate verification failed at depth 0: self-signed certificate.

Hm.  This example works fine for me on RHEL8.  Evidently your
openssl installation is set up to reject self-signed certificates
by default.  I note that in my installation, /etc/pki/tls/openssl.cnf
contains

[ req ]
...
x509_extensions    = v3_ca    # The extensions to add to the self signed cert
...
[ v3_ca ]
# Extensions for a typical CA
...
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign

Perhaps in your configuration file, that option is active?

            regards, tom lane

On Sun, Jun 8, 2025 at 9:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm.  This example works fine for me on RHEL8.  Evidently your
> openssl installation is set up to reject self-signed certificates
> by default.

I wonder if this setup is somewhat undefined/underdefined behavior.

Andrus, if I understand correctly, you have
- two certificates (one client, one server _and_ CA)
- with the same(!) Subject, according to the logs
- one signed the other (so it's "self-signed")
- one is marked CA, one is not

I have no idea how OpenSSL or the RFCs resolve this situation. Do you
really intend to have the CA share the same Subject as the client?

--Jacob

Hi!

I wonder if this setup is somewhat undefined/underdefined behavior.

Andrus, if I understand correctly, you have
- two certificates (one client, one server _and_ CA)
- with the same(!) Subject, according to the logs
- one signed the other (so it's "self-signed")
- one is marked CA, one is not

I have no idea how OpenSSL or the RFCs resolve this situation. Do you
really intend to have the CA share the same Subject as the client?

No. It was mistake. You can close this bug report as invalid.

Andrus.