View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000751 | Pgpool-II | General | public | 2022-04-01 12:35 | 2022-06-02 13:48 |
| Reporter | ProNibs | Assigned To | pengbo | ||
| Priority | low | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Product Version | 4.3.1 | ||||
| Summary | 0000751: Why does pgpool lock in SSL on server start? | ||||
| Description | Just looking for context for the title here. For my specific use case, running pgpool in a Kubernetes cluster with TLS enabled typically uses cert-manager. Cert manager will auto-renew certificates and the underlying SSL certs. However, since pgpool locks in the SSL certificates on process start, it cannot pick up on the change to the file. Would be great for either pgpool to pick up the new certs whenever updates (docs are pretty explicit it does not) or have an easy way to get the process to exit or crash on the next pgpool client connection where the certs don’t match. | ||||
| Tags | No tags attached. | ||||
|
|
Sorry. I am not familiar with cert-manager. How did you verify that pgpool locks in the SSL certificates. Are there any error messages? |
|
|
There are no errors on the pgpool side, just the app side. Essentially, both a client and pgpool will have the certificate files. Cert-manager plus some Kubernetes magic essentially just change those underlying files at the same time for you. It’s equivalent to a server admin going in and manually changing those files. After rotating the certificate files, the app will pick up the new file and then on its next call to pgpool will get certificate errors. If you have pgpool logging on, you’ll also see a similar warning about how a client attempted to connect with the wrong certificate. This can be confirmed standup by standing up pgpool, running OpenSSL to view the cert currently served, change the file, wait a few minutes, run the OpenSSL command again and notice it does not change until the server restarts. Sample command: openssl s_client -starttls postgres -connect localhost:5432 | openssl x509 -text -noout |
|
|
Thank you. It is the expected behavior. Pgpool-II reads the certification files at startup, and saves the certifications in memory. To update the certifications loaded by Pgpool-II, you must restart Pgpool-II. |
|
|
Yep, understand that’s the default and expected behavior. Was looking for an explanation of why that’s the case versus checking the certificate at runtime, such as a security or technical limitation. |
|
|
Reading from memory is faster than the disk. I think PostgreSQL is using the same way. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-04-01 12:35 | ProNibs | New Issue | |
| 2022-04-04 00:28 | pengbo | Note Added: 0004017 | |
| 2022-04-04 00:29 | pengbo | Assigned To | => pengbo |
| 2022-04-04 00:29 | pengbo | Status | new => feedback |
| 2022-04-04 00:49 | ProNibs | Note Added: 0004018 | |
| 2022-04-04 00:49 | ProNibs | Status | feedback => assigned |
| 2022-04-04 11:58 | pengbo | Note Added: 0004019 | |
| 2022-04-04 11:58 | pengbo | Status | assigned => feedback |
| 2022-04-05 06:16 | ProNibs | Note Added: 0004022 | |
| 2022-04-05 06:16 | ProNibs | Status | feedback => assigned |
| 2022-04-05 12:39 | pengbo | Note Added: 0004023 | |
| 2022-04-05 12:39 | pengbo | Status | assigned => feedback |
| 2022-06-02 13:48 | administrator | Status | feedback => closed |
