You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the documentation over at EDB docs for securing pg-backup-api goes into detail about how to configure with self-signed certificates but provides very little help for anyone using certificates signed by a trusted CA.
Given many users will either have their own internal CA or be using certificates signed by a trusted third party, this is not really enough to allow customers to configure pg-backup-api or to allow support to help customers - in fact the bias in the document towards self signed certificates is actively unhelpful. There were good reasons for focusing on self-signed certificates at the time but we need to have equivalent detail for using third party certificates.
The main missing pieces are:
The ssl_ca_crt value in the agent.cfg file must point to a certificate bundle which contains a chain of certificates which include the CA which signed the server certificate and, if that CA is not a root CA, all intermediate certificates leading back to the root CA and the root CA certificate. This may be a single certificate (as is the case with self-signed certificates) or it could be an existing bundle on the system (if a user is using a trusted third party such as LetsEncrypt). The key point is that pemagent will not find any certificates on the system unless ssl_ca_crt is set. If it is not set it will complain with something like:
Wed Jul 6 09:31:23 2022 WARNING: [BARMAN #3 #502] [Status API] Error Message: CURL(pemAgent Barman Monitoring (#3,1)): 77 Problem with the SSL CA cert (path
? access rights?) error setting certificate verify locations:
CAfile: ca-bundle.crt
CApath: none
Setting ssl_ca_crt is a bit of a pain if the two other ssl parameters to the pemworker --register-barman command are not used because registration will fail. It is therefore necessary to omit the parameter and edit agent.cfg manually.
Register:
$ /usr/edb/pem/agent/bin/pemworker --register-barman --api-url https://foo.bar.backup.org --description 'barman-api' --owner enterprisedb -c /usr/edb/pem/agent/etc/agent.cfg
Barman API successfully registered!
BARMAN ID: 4
** NOTE: Please restart the pemAgent to take these changes in effect.
Edit agent.cfg adding a [BARMAN/ID] section where ID is the BARMAN ID value in the output of the registration command.(BARMAN/4 is used here):
It's worth emphasizing the importance of matching the barman ID at registration time and the barman ID in agent.cfg. It's also worth emphasizing ssl_ca_crt must point to a file which contains the correct certificates. Possibly give some example openssl commands which can be used to verify this (or at least curl).
Also, many organisations will not configure Apache httpd directly on the Barman server and will likely use something else to proxy connections to pg-backup-api. If so, all references to pgbapi.conf in the Apache config will be unhelpful - we need to be a bit clearer about this in the docs too - i.e. "this is one way of setting things up" and perhaps at the top be very clear about what is required before we get into how we suggest implementing it with httpd and certificates.
The text was updated successfully, but these errors were encountered:
Currently the documentation over at EDB docs for securing pg-backup-api goes into detail about how to configure with self-signed certificates but provides very little help for anyone using certificates signed by a trusted CA.
Given many users will either have their own internal CA or be using certificates signed by a trusted third party, this is not really enough to allow customers to configure pg-backup-api or to allow support to help customers - in fact the bias in the document towards self signed certificates is actively unhelpful. There were good reasons for focusing on self-signed certificates at the time but we need to have equivalent detail for using third party certificates.
The main missing pieces are:
ssl_ca_crt
value in theagent.cfg
file must point to a certificate bundle which contains a chain of certificates which include the CA which signed the server certificate and, if that CA is not a root CA, all intermediate certificates leading back to the root CA and the root CA certificate. This may be a single certificate (as is the case with self-signed certificates) or it could be an existing bundle on the system (if a user is using a trusted third party such as LetsEncrypt). The key point is that pemagent will not find any certificates on the system unlessssl_ca_crt
is set. If it is not set it will complain with something like:ssl_ca_crt
is a bit of a pain if the two other ssl parameters to the pemworker--register-barman
command are not used because registration will fail. It is therefore necessary to omit the parameter and edit agent.cfg manually.[BARMAN/ID]
section whereID
is theBARMAN ID
value in the output of the registration command.(BARMAN/4
is used here):pemagent
.It's worth emphasizing the importance of matching the barman ID at registration time and the barman ID in agent.cfg. It's also worth emphasizing
ssl_ca_crt
must point to a file which contains the correct certificates. Possibly give some example openssl commands which can be used to verify this (or at least curl).Also, many organisations will not configure Apache httpd directly on the Barman server and will likely use something else to proxy connections to pg-backup-api. If so, all references to
pgbapi.conf
in the Apache config will be unhelpful - we need to be a bit clearer about this in the docs too - i.e. "this is one way of setting things up" and perhaps at the top be very clear about what is required before we get into how we suggest implementing it with httpd and certificates.The text was updated successfully, but these errors were encountered: