Very much so. We have public and private keys – only the symlinks to them are stable – and access to them (as installed by certbot) is controlled by discretionary permissions on the grandparent directories, namely, owner root, group root, mode 0700 for
Files in the /etc/ hierarchy are automatically assigned SELinux security context type “etc_t”. PostgreSQL runs as user “postgres” group “postgres” and does not have the mandatory access control permissions to read files of type “etc_t”.
Changing the SELinux security context type of the files to make them readable by PostgreSQL makes them unreadable by other programs such as web servers which are not supposed to be allowed under MAC policy to read raw database files directly, but only by connecting to the database.
The suggestion of a separate certificate for the database is not completely unreasonable, except that I like to be economical: while they are apparently free at “letsencrypt”, some providers charge for them.
The “deploy hook” will have to set umask, copy the key and certificate chain over, change the owner:group to “postgres:postgres”, and set the SELinux mandatory access control security context type to “postgresql_db_t”.
It is not that I don’t trust PostgreSQL or that I don’t want user “postgres” to have access to the keys; it is just that this is the trouble I must go through to make that happen, without allowing unauthorized access to the keys.
Getting a separate certificate for the database would not do anything to make it easier to make the keys readable by the database server.
EDIT: THIS HAS BEEN TAKEN OUT OF CONTEXT. DO NOT FOLLOW THESE INSTRUCTIONS. USE THE DEPLOY HOOK IN MY FOLLOWING POST.