If by "SSL Encryption", you mean encryption of TCP connection to the SQL Server instance, then you'll need to generate a certificate using the Fully Qualified Domain Name (FQDN) (I use OpenSSL to generate these, and sign them with a CA that's loaded on the domain controller), load them on the SQL Server's host OS "Computer" store, and then use SQL Server Configuration Manager to select them (and, optionally, Force Encryption to on).

Personally, I like forcing encryption to be on; I feel much better when traffic's encrypted.

Pros:

You may have a fighting chance at some security recommendations or requirements for your industry.

You can give one more "good" answer on audits.

It's more difficult for attackers on your network to obtain possible sensitive information.

Cons:

To use packet sniffers to see SQL, you'll also need to load the certificate into the packet sniffer.

In some cases, users should use the FQDN to avoid certificate warnings, "server.domain.top" instead of "server"

For first pass validation:

SELECT encrypt_option, auth_scheme, count(*)

FROM sys.dm_exec_connections

GROUP BY encrypt_option, auth_scheme

ORDER BY encrypt_option, auth_scheme

Better validation involves packet sniffers; at this time I'm not sure how to extract precisely which cipher suite is being used.