The Postgres client library supports SSL directly, so what you're really looking to do here is just pass configuration parameters to libpostgres. Pretty much every configuration parameter can be specified on the $dsn, so you should be able to borrow configuration examples from any language, not just perl. You could even choose to pass some of them by environment variable, so that your perl script doesn't need to specify them directly. Another great option is to reference configured services in the standard postgres ~/.pg_service.conf file. This is documented in connect of DBD::Pg:

You can also connect by using a service connection file. Service names can be defined in either a per-user service file or a system-wide file. If the same service name exists in both the user and the system file, the user file takes precedence. By default, the per-user service file is named ~/.pg_service.conf. On Microsoft Windows, it is named %APPDATA% \postgresql\.pg_service.conf (where %APPDATA% refers to the Application Data subdirectory in the user's profile). A different file name can be specified by setting the environment variable PGSERVICEFILE. The system-wide file is named pg_service.conf. The location of this file can be controlled by setting the PGSYSCONFDIR environment variable. To use one of the named services within the file, set the name by using either the service parameter or the environment variable PGSERVICE. Note that when connecting this way, only the minimum parameters should be used. For example, to connect to a service named "zephyr", you could use:

$dbh = DBI->connect("dbi:Pg:service=zephyr", '', '');
[download]

You could also set $ENV{PGSERVICE} to "zephyr" and connect like this:

$dbh = DBI->connect("dbi:Pg:", '', '');
[download]

To isolate problems related to perl, you can use that same config file for standard pg commandline tools like 'psql'. If psql -d service=myservicename can connect, then perl should also.

This also saves you from needing to alter the script when you deploy it in different environments. And with a single environment variable, you can override whether it's connecting to the production DB or your local copy for testing.