With security in SQL Server, one needs to be very watchful that permissions are not indirectly granted when not intended. Designing granular permissions for the SQL Server system must be a very meticulous task for Microsoft. Once created, the certificate can be altered, but only to drop the private key. View definition lets the user see the metadata, however when it comes to the private key this is not enough because it is encrypted by the database master key, which, in turn is encrypted by the service master key. Besides, the documentation states that "view definition does not imply access to the securable itself". References permission as well is not enough for a certificate, however, it is enough to use a symmetric key. The user of encryption needs control permissions.
There are several very good reasons why the other answer recommends designing stored procedures to read and write encrypted data using code signing. Anyone with the control permission on a certificate can back up the certificate and private key to the file system. By code signing, you don't need to grant control directly to any user as the additional permissions are made available by associating a certificate user with permissions with the procedure through code signing. Also, anyone with control permissions can grant permissions on the securable to others, which could lead to some surreptitious activity. The db_owner role, db_securityadmin and the db_ddladmin role have CONTROL permissions on certificates automatically and the db_backupoperator role can back up the database.
Although it seems that you are asking about column encryption. Certificates with SQL Server are created in master and msdb for other purposes, such as Transparent Data Encryption and backup encryption. Stolen certificates can be used to defeat these. So don't allow anyone in the roles mentioned above in master or msdb.