0

We run a SaaS (software as a service) company where we allow multiple clients to create "sites" within our application.

This typically results in the client having a site that is a subdomain of our main domain. eg: someclient.mybusiness.com

We support SSL for checkout, and have a single wildcard certificate so that all clients are covered (since they are all on *.mybusiness.com)

We now want to begin offering custom domain names. In this case, the clients would still have their site as someclient.mybusiness.com, but could go to their hosting provider and create a CNAME pointing to someclient.mybusiness.com. So as a result, they could have buystuff.clientsite.com pointing to someclient.mybusiness.com.

My question is how best to go about supporting SSL for those clients that want to use the custom domain option?

I've read about SAN, but I'm not sure how that would work with our existing wildcard cert.

I've also read about SNI, but that would require that our clients purchase their own certs, which our marketing department would prefer to not be the case.

Any thoughts on this are greatly appreciated!

Matt

  • I'd use a UCC/SAN certificate (can have up to 100 domains on one) and maybe something like Namecheap's SSL API to provision them. – ceejayoz Jun 3 '15 at 22:01
  • I'd use SNI and make the customers buy an ssl certificate. – Some Linux Nerd Jun 3 '15 at 22:12
  • ceejayoz - If I was to use SAN, could I use that in place of my wildcard cert? By that I mean could I have a wildcard domain within the SAN cert? Or would I have to maintain the wildcard cert separately? – Matt P Jun 3 '15 at 22:43
  • Some Linux Nerd - Thanks, I will probably also have to support this :( – Matt P Jun 3 '15 at 22:44
  • @MattP You'd need two certs. I'm not aware of a provider that allows a wildcard entry in a SAN cert (although I think it's technically possible). – ceejayoz Jun 4 '15 at 14:41
3

The whole point of trusted-authority-signed SSL certificates is to stop entity A pretending to be entity B[1] without entity B's consent, and your marketing department is going to have to live with this. No reputable provider is going to sign a CSR from you that specifies someone else's FQDN, either principally or in the SAN field, without a lot of involvement from that someone else.

My advice would be to accept this, use SNI, and have a business process whereby you generate the keypair and the CSR, which you then pass to the client with some very precise, step-by-step instructions as to how to get that signed by a particular preferred provider. That doesn't bind the customer to use that provider - those with clue can get the CSR signed by any valid provider - but it minimises the chance of complications for clients that don't have that clue.

[1] To be precise, to stop entity A offering SSL-secured services where the certificate contains a CN in entity B's DNS space.

  • "No reputable provider is going to sign a CSR from you that specifies someone else's FQDN, either principally or in the SAN field, without a lot of involvement from that someone else." If the domain is pointed at their servers, many SSL providers allow verification via a DNS record, which they'd be able to put in place w/o client action. I do this frequently. – ceejayoz Jun 4 '15 at 14:42
  • I consider getting someone else to put a DNS record in place to constitute a lot of involvement, but it's very interesting to hear that that procedure suffices for at least some CAs. The OP might find it interesting to know which CAs will consider that scheme; do you feel like sharing? – MadHatter supports Monica Jun 4 '15 at 14:45
  • Comodo permits DNS-based verification. We had our clients delegate their domains that they pointed at us so we could do the DNS on our end without their involvement past initial setup. Worked well. – ceejayoz Jun 4 '15 at 15:08
  • Thanks for the feedback, all. I have a couple of meetings on this today, so now I'll at least be a little better informed! – Matt P Jun 4 '15 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.