A resposta acima pode ser um pouco datada. Os aplicativos SaaS modernos que desejam servir SSL para vários domínios de clientes usarão o SNI. SNI é "Server Name Indication" (RFC 6066; RFC 4366, RFC 3566) é uma extensão do Transport Layer Security que permite ao cliente informar ao servidor o nome do host que está tentando acessar.
Isso é muito mais eficiente do que as formas mais antigas de lidar com isso, como o UCC ou, pior ainda, 1 IP por certificado. É também por isso que, tradicionalmente, obter domínios personalizados protegidos seria um custo que é passado para o cliente. Era e é bastante comum ver a plataforma cobrando $ X / mo para domínios personalizados como um recurso adicional. Isso é por causa dos custos envolvidos na execução de domínios personalizados.
Se você deseja desenvolver algo assim hoje, comece com o SNI e atenda aos certificados dessa maneira. Dependendo da sua pilha, isso pode ser muito fácil de fazer (NodeJS) ou muito difícil (tradicionais app-proxies baseados em apache / nginx). Normalmente, a dificuldade é aceitar a solicitação SNI de entrada e combiná-la com o banco de dados ou outra lógica do aplicativo para garantir que você esteja atendendo ao certificado correto para essa solicitação.
Como mencionado, você pode estar com sorte se estiver usando o Node. Existem algumas ótimas bibliotecas que ajudam com isso se você deseja servir certificados fornecidos pelo Let's Encrypt e deseja fornecer dinamicamente um certificado com base nos dados da solicitação recebida. Por exemplo, o link é uma biblioteca que ajuda você com isso.
Por último, se você está procurando uma solução de terceiros, há o link , que basicamente permite que você ignore as dificuldades de exibir certificados SSL do SNI oferecendo-o como um serviço se você não estiver particularmente interessado em gerenciar e manter sua própria camada SNI.