Hmmm.... Is that the right port for SSL/TLS if it is it looks like it isn't
just a a case of connecting to the right port to get an SSL/TLS connection. Might be some STARTTLS equivalent but I'm not sure what it is for that
application.

PostgreSQL always listens on one port. This is the only port I ever used for 
TCP/IP connections. So there must be something like STARTTLS, as it can handle 
both encrypted and unencrypted connections.

        [EMAIL PROTECTED] ~]# netstat -atpn | grep postgres | grep LISTEN
        tcp        0      0 10.84.53.1:5432         0.0.0.0:*               
LISTEN      9808/postgres
        tcp        0      0 10.84.55.1:5432         0.0.0.0:*               
LISTEN      9808/postgres
        tcp        0      0 217.112.173.73:5432     0.0.0.0:*               
LISTEN      9808/postgres
        tcp        0      0 127.0.0.1:5432          0.0.0.0:*               
LISTEN      9808/postgres
        tcp        0      0 2002:d970:ad49:2:::5432 :::*                    
LISTEN      9808/postgres
        tcp        0      0 2002:d970:ad49:1:::5432 :::*                    
LISTEN      9808/postgres
        tcp        0      0 2002:d970:ad49::1:5432  :::*                    
LISTEN      9808/postgres
        tcp        0      0 ::1:5432                :::*                    
LISTEN      9808/postgres

It looks like an expired certificate is somehow being used. How isn't clear at
this stage. If you have CA certificates in directories or files make sure an
old one isn't in there.

I only have one directory and one CA certificate. That makes the task simple.

On the client:
        [EMAIL PROTECTED] .postgresql]$ openssl x509 -in postgresql.crt -text | 
grep Not
                    Not Before: Mar 25 12:00:00 2008 GMT
                    Not After : Mar 25 12:00:00 2009 GMT
        [EMAIL PROTECTED] .postgresql]$ openssl x509 -in root.crt -text | grep 
Not
                    Not Before: Nov 12 16:03:00 2006 GMT
                    Not After : Nov 11 16:03:00 2011 GMT
On the server:
        [EMAIL PROTECTED] data]# openssl x509 -in server.crt -text | grep Not
                    Not Before: Jul 23 09:20:00 2008 GMT
                    Not After : Jul 23 09:20:00 2009 GMT
        [EMAIL PROTECTED] data]# openssl x509 -in root.crt -text | grep Not
                    Not Before: Nov 12 16:03:00 2006 GMT
                    Not After : Nov 11 16:03:00 2011 GMT

The best I can suggest at this point is modifying OpenSSL or the application to
dump out any expired certificates to a temp file so you can see which one(s)
it is complaining about.

That would be helpful. But how could I do that? What file should I change? Is 
there a patch/howto?

Two more remarks:
        1) Downgraded to h and restarted PostgreSQL today. (Grrr...) Still the 
same error.
        2) Just a wild guess, a shot in the dark: Could this be a 
locale-related issue? Does OpenSSL use/parse text representations of dates and 
times? If so, getting (for example) '9. říj 15.12' instead of 'Oct 9 15:12' 
could result in a comparison failure if not handled properly. (But this is 
probably not the case. Presumably, a binary representation (such as epoch) is 
used...)

Andrej

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to