I'm wondering what best practices are regarding delegating the authority to approve SSL certificate issuance.
One of our vendors (www.vendordomain.com) will soon host a Web application for us (www.mydomain.com) with an SaaS approach. The Web application will be hosted in one of our subdomains (theservice.mydomain.com), and will of course be protected with SSL. Both our organization and the vendor are large organizations (thousands to tens of thousands of users); we are not talking about a mom-and-pop operation here.
As part of the package, the vendor insists that they will obtain the SSL certificate from their CA. They flat out refuse to send us a CSR so we can get a certificate from our CA.
I just found out that the reason they do that is that they are using a single SSL certificate for all of their clients, with each client listed as a Subject Alternate Name.
To me, this seems very far removed from best practices. Am I wrong - have best practices changed in the cloud-centric SaaS world? Or is this vendor simply exploiting their near-monopoly position to push bad practices for their convenience?
And if this is not best practice, how serious an issue is this? My initial response had been "No. Heck No!" Or should it be a more muted "Not a great idea, but it's tolerable?"
I also see a number of specific technical concerns, and am wondering how serious they are:
- Wouldn't this approach break any CAA records?
- Can such an approach work with EV certificates?
- Is using a single certificate with all of their clients as Subject Alternate Names a security concern? I'm concerned that a hacker may use that information break into one of the other sites on the same server, and then leverage that to penetrate our data on the server.
Finally, a very broad question: Would this be something a security audit may flag (assuming it's within the scope of the audit, of course), or be an issue with any of the various data security or privacy regulations?