You really want to avoid putting too many SANs on a certificate as i) renewal breaks much more frequently; ii) certificate size increases/negatively affects per

You really want to avoid putting too many SANs on a certificate as i) renewal breaks much more frequently; ii) certificate size increases/negatively affects performance due to fragmentation and; iii) browsers many lock up (if you like to live dangerously, try loading https://10000-sans.badssl.com/ https://10000-sans.badssl.com/ for example). The biggest operational headache by far is on renewals. If one customer on a commingled certificate adds a CAA record that doesn't include your CA of choice (or more commonly, the customer churns and no longer points to you), your renewal fails. If you're running a SaaS business you really want one certificate per hostname that's lazy loaded based on the incoming SNI. This keeps renewal failures and support costs down, and keeps customers from seeing a list of their competitors on their certificate. As @elithar points out, that's why we built SSL for SaaS. You make a single API call with the name of the hostname you want a certificate issued for, indicate the validation method (HTTP ./well-known is by far the "happiest path"), and then in about a minute you've got a certificate deployed worldwide. You tell us where to route traffic back to by providing a default origin (which can be a load balancer) and optionally overriding it on a per-hostname basis. So long as your customer is CNAME'ing to your domain and that domain resolves to Cloudflare's edge, we can automatically complete—and keep completing—domain control validation (DCV). We then issue two certificates per hostname: one P-256 keyed, SHA-2/ECDSA signed certificate that gets presented to modern browsers[1] and one RSA 2048-bit, SHA-2/RSA signed certificate that gets presented to browsers that don't support ECC. 1 - https://blog.cloudflare.com/tls-certificate-optimization-technical-details/ https://blog.cloudflare.com/tls-certificate-optimization-tec...