Hi, I'm going to be hosting DotNetNuke for several clients.  Would best practice be to give them each a separate instance of DotNetNuke, or to have 1 installation with multiple portals?

Also, if I have 1 installation with multiple portals, does DNN support separate SSL certificates for each portal?

Any client that may require DB access or application-file-level access needs to have a dedicated DNN instance.  DB data from all portals are mixed together in the same tables so you can't grant a client special read access to any DNN DB tables without inherently granting that client read access to other clients' data.  If, for example, a client requires a popular third-party module such as Dynamic Registration or XMOD then that client will have the ability to read data from any table in the DB.  Even the default DNN Reports module is a data security issue in a multi-client, multi-portal environment.
 
If your clients have very basic website requirements without any special data access then, as Sebastian said, a multi-portal instance should work fine.  I've run separate sites on up to 30 portals on a single instance (though all the sites were for the same client so data access was not an issue).
 
 
Regarding shared SSL across portals:
It really depends on how you intend to configure your portals.  If you configure DNN to have child portals based folder name such as "mysite.com/clientA", "mysite.com/clientB", etc, then a single SSL certificate for "mysite.com" should suffice.  If you use subdomains such as "clientA.mysite.com", "clientB.mysite.com", etc., then you'll need a more expensive "wildcard" certificate.  If you want to have different domains for each portal such as "clientA.com", "clientB.com", etc, then you'll need a separate certificate for each portal (same as if you had separate DNN installations).  The only way to leverage one SSL across multiple domains is through a shared certificate.  This is fairly common in shared-hosting environments.  A shared certificate will have its own domain and any DNN pages you elect to have protected will have their domain changed to the certificate's domain when you browse to those pages.  This can be confusing to your end users as the URL will make it appear as if you've changed websites when you browse to a SSL-protected page.  You may also run into authentication issues with protected content and logged-in users since a user's status will show the user as being authenticated for one domain but not for the both -- in other words, a logged-in user could be prompted to log in again when switching between "password-protected" SSL and "password-protected" non-SSL pages .  
  
Generally it's best to have one dedicated certificate per domain (if you can afford it).
 
Cheers!
-mamlin