I previouslymentionedthe importance of high qualitydocumentation,so we are always looking for improvements. This emailthreadfrom 2013 attempted to codify the rules for how to properly use intermediatessl/tlscertificates with Postgres. At this time, our documentation wasupdatedto recommend storing intermediate certificates with root certificates because it was unclear under what circumstances intermediate certificates are transferred to the remote server to be chained to a trusted root certificate.
During research for my foursecurity talks,I studied certificate handling. I found certificate chain resolutionrulesin theverifymanual page. In testing various certificate locations, I alsofoundthat Postgres follows the same rules.
Based on this testing, I realized the conclusions reached in 2013 were inaccurate, or at least incomplete. While the documented procedure worked, the more practical and recommended approach is to store intermediate certificates (created withv3_caextensions) with leaf certificates to be sent to the remote end.
This new procedure allows short-lived leaf and intermediate certificates to be replaced at expire time while long-lived root certificate stores remains unchanged. For example, for clients to verify the server's certificate, the server would contain the intermediate and server's leaf certificates, and clients only need root certificates, which rarely change.
The documentation of all supported Postgres versions has beenupdatedto recommend this new procedure. I have also added sample scripts showing how to create root-leaf and root-intermediate-leaf certificate chains.
These changes will be distributed in the next minor Postgres releases,scheduledfor next month. Until this new documentation is released, you can read the updates in the Postgres 11 docs in theserverandlibpqsslsections. I am hopeful this clarified documentation will encourage people to usessl andsslcertificate verification.