According to chapter 6.3.9.3 Configuring MySQL to Use SSL Connections of the MySQL 5.5 Reference Manual your client has to be invoked with the --ssl-ca option.

shell> mysql --ssl-ca=ca.pem

If the user account is required to provide a client certificate, then you need to invoke the client also with --ssl-cert and --ssl-key.

shell> mysql --ssl-ca=ca.pem \
             --ssl-cert=client-cert.pem \
             --ssl-key=client-key.pem

To check if you're connected via SSL, the Ssl_cipher variable has to be nonempty

mysql> SHOW STATUS LIKE 'Ssl_cipher';

You might also take a look at chapter 6.3.10 Creating SSL Certificates and Keys Using openssl.

Follow up:

And since you wanna realize replication via SSL 17.3.7 Setting Up Replication Using SSL also applies.

Data-at-rest

There may be a terminology problem here. Data-at-rest encryption usually means

1. Storage-encryption
2. Not peer-to-peer nor any other form of data-at-use encryption.

On the forms of encryption suggested, I would advise staying away from those RDBMS-specific solutions as they're less tested than the other options which PostgreSQL suggests

Storage encryption can be performed at the file system level or the block level. Linux file system encryption options include eCryptfs and EncFS, while FreeBSD uses PEFS. Block level or full disk encryption options include dm-crypt + LUKS on Linux and GEOM modules geli and gbde on FreeBSD. Many other operating systems support this functionality, including Windows.

This mechanism prevents unencrypted data from being read from the drives if the drives or the entire computer is stolen. This does not protect against attacks while the file system is mounted, because when mounted, the operating system provides an unencrypted view of the data. However, to mount the file system, you need some way for the encryption key to be passed to the operating system, and sometimes the key is stored somewhere on the host that mounts the disk.

Essentially, different operating systems and file systems abstraction layers provide a better better-tested method of handling data-at-rest encryption.

Yes, that means you have a key. Yes, that means if the key is compromised the data can be read. But if your database is compromised and not the key, the data is secure. And, that's why it's data-at-rest.

So you normally store the key owned by root. Have root mount the secured location, and let the postgres user access that. Obviously PostgreSQL needs access to the data and has to know how to decrypt it.

Now, if other users are on the machine they can't access the data unless they're they postgres user. Moreover, they can't access the key. And if they do manage to compromise the data or even steal the physical encrypted back up they can't access it without the key.