4 ms·

We use wildcard certs (*.example.com) so each customer can have vanity-customer-name.example.com domains. I think our model is fairly common for multi-tenant do

by helper 8y ago

We use wildcard certs (*.example.com) so each customer can have vanity-customer-name.example.com domains. I think our model is fairly common for multi-tenant domain name segregated systems.

clon 8y ago
We do that as well for the cheaper packages. But serious users insist on a our-service.client.com "vanity" scheme, which is easy enough with CNAME records, apart from TLS that adds significant cost. For example, Application Load Balancers (ALB) come with a limit of max 25 certificates, which is non-starter for us. So you cannot avoid terminating your TLS in nginx/caddy etc (it also needs to be HA of course) and then hit another LB that stands in front of the actual service. You end up with a 2-layer LB architecture that adds cost and complexity.
- web007 8y ago
  Can you bundle your certificates the way Cloudflare does? IIRC if you connect to a CF endpoint you will get a certificate with N arbitrary hostnames that are being served by that endpoint. I don't know what the SNI hostname limit is, but it's probably stupidly high. Multiply that by 25 and it may be tenable?
  - elithrar 8y ago
    Cloudflare has a service that does this automatically - they call it "SSL for SaaS" - and you can provision custom/vanity hostnames onto their own certificates within a minute or so + push to the edge. You should reach out to https://twitter.com/prdonahue https://twitter.com/prdonahue (PM), who can share the details. (Used to work there, now at GCP)
  - prdonahue 8y ago
    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...
    - clon 8y ago
      Issuing SAN-s with multiple tenants on the same certificate, even if the substantial technical problems were overcame, would make our clients reach for pitchforks and torches. > You make a single API call with the name of the hostname you want a certificate issued for ... [magic TLS things happen] This, precisely, is how the ALB _should_ work, without a silly 25-certificate limitation. Sounds like an excellent service. I wonder what is the cost of issuance for a TLS certificate. There is minimal storage/network load, some computations (likely in hardware). Perhaps the main cost is the collection of sufficient entropy?
- jdub 8y ago
  Use multi-SAN certificates. Yes, it means revealing who is using your service, but that's for you and your customers to weigh against the costs.
  - ngrilly 8y ago
    This is what I do, but that's a lot of accidental complexity. Here is what Caddy's author wrote about this: > I still don't like the idea of SAN certificates. Too much room for error... what if you go to renew a SAN and one of the domains fail, the other 99 don't get renewed either. (Sure, we can code in logic to make a different certificate with 99 names, but that gets complicated quickly.) Also, we'd need a database as we have a many-to-many relationship rather than 1:1 which is much easier. Source: https://github.com/mholt/caddy/issues/831#issuecomment-220110365 https://github.com/mholt/caddy/issues/831#issuecomment-22011...

by helper 8y ago

We use wildcard certs (*.example.com) so each customer can have vanity-customer-name.example.com domains. I think our model is fairly common for multi-tenant domain name segregated systems.

clon 8y ago

We do that as well for the cheaper packages. But serious users insist on a our-service.client.com "vanity" scheme, which is easy enough with CNAME records, apart from TLS that adds significant cost. For example, Application Load Balancers (ALB) come with a limit of max 25 certificates, which is non-starter for us. So you cannot avoid terminating your TLS in nginx/caddy etc (it also needs to be HA of course) and then hit another LB that stands in front of the actual service. You end up with a 2-layer LB architecture that adds cost and complexity.

web007 8y ago
Can you bundle your certificates the way Cloudflare does? IIRC if you connect to a CF endpoint you will get a certificate with N arbitrary hostnames that are being served by that endpoint. I don't know what the SNI hostname limit is, but it's probably stupidly high. Multiply that by 25 and it may be tenable?
- elithrar 8y ago
  Cloudflare has a service that does this automatically - they call it "SSL for SaaS" - and you can provision custom/vanity hostnames onto their own certificates within a minute or so + push to the edge. You should reach out to https://twitter.com/prdonahue https://twitter.com/prdonahue (PM), who can share the details. (Used to work there, now at GCP)
- prdonahue 8y ago
  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...
  - clon 8y ago
    Issuing SAN-s with multiple tenants on the same certificate, even if the substantial technical problems were overcame, would make our clients reach for pitchforks and torches. > You make a single API call with the name of the hostname you want a certificate issued for ... [magic TLS things happen] This, precisely, is how the ALB _should_ work, without a silly 25-certificate limitation. Sounds like an excellent service. I wonder what is the cost of issuance for a TLS certificate. There is minimal storage/network load, some computations (likely in hardware). Perhaps the main cost is the collection of sufficient entropy?
jdub 8y ago
Use multi-SAN certificates. Yes, it means revealing who is using your service, but that's for you and your customers to weigh against the costs.
- ngrilly 8y ago
  This is what I do, but that's a lot of accidental complexity. Here is what Caddy's author wrote about this: > I still don't like the idea of SAN certificates. Too much room for error... what if you go to renew a SAN and one of the domains fail, the other 99 don't get renewed either. (Sure, we can code in logic to make a different certificate with 99 names, but that gets complicated quickly.) Also, we'd need a database as we have a many-to-many relationship rather than 1:1 which is much easier. Source: https://github.com/mholt/caddy/issues/831#issuecomment-220110365 https://github.com/mholt/caddy/issues/831#issuecomment-22011...