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?

  • I don't like it, and they certainly don't need to do it this way. Many of their clients are listed in that certificate. Additionally, each domain adds to the certificate's size. EV certificates won't work in this scenario. I don't believe this is much of a security concern though. There is disclosure with this method, but creating individual certs also discloses those domains if the CA complies with Certificate Transparency. – Aaron Cicali Sep 27 '18 at 16:53
  • @AaronCicali The disclosure I was worried about is that the various clients share a certificate, and likely a server. Certificate transparency would only disclose that the various certificates exist. – Kevin Keane Sep 27 '18 at 17:00
  • True, but that information could also be gathered by someone scraping CT logs and translating hostnames to IP addresses. If I were in your position, this configuration by this 3rd party service might cause me to consider what other poor choices they've made within their offering. – Aaron Cicali Sep 27 '18 at 18:11
  • @AaronCicali Agreed on the other poor choices; this isn't the first issue that came up. That's why my spidey sense is on high alert with them. Translating host names to IP address would not be a practical way to collect that information because an attacker wouldn't know which host names to look for in the first place. – Kevin Keane Sep 27 '18 at 18:21
  • No arguments here. Re: "an attacker wouldn't know which host names to look for"... All of them - every single one. – Aaron Cicali Sep 28 '18 at 21:09

Your Answer

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

Browse other questions tagged or ask your own question.