Why would device manufacturer refuse to publish root CA that signs devices but provides the CA



  • Background:

    We got a few new model SIP phones. Each phone has built-in unique certificate issued by the manufacturer.

    Previous models had certs issued by a different CA and that CA cert was published, so I could verify the phone's identity as it gets provisioned starting from the factory default state.

    Manufacturer's support refused to publish new CA cert but after some questions and days later provided it as an attachment my support ticket. This took days. No NDAs were requested. If I was in charge of my company security I would be concerned if my colleague gives me CA certificates and says they obtained it directly from the phones' manufacturer and asks me to install the CA cert as trusted on the provisioning server. I would have liked to see this CA cert published on the manufacturer's web site in resources/downloads for the model. I explained exactly that to the manufacturer's support but they refused, citing security concerns. Some back and forth, latest ones are:

    Some customers told us there is a security issue if CA files show on support website. There is a rule internally, if customer wants new CA files, we need to apply with our PM one by one.

    I've looked at the data in the certificates; there is very little there, generic email address support@domainname... that gets auto-replied with "nobody here", company domain name, name of city and province in China, nothing else that I would find interesting, but I am not an expert in this field. Even if there was anything potentially dangerous, they give out these to anybody patient enough to ask, it is no longer a secret.

    It is my understanding that it is in the manufacturer's interests to publish these certificates to allow their customers to obtain the correct certificate easily, and not be tempted to find one somebody claims to have obtained earlier and helpfully re-distributes.

    So my questions are these:

    • What are the risks to the manufacturer that would justify complicating release of these CA certificates to their users.

    • Is there a risk to the user e.g. the user happens to do a web search and comes across a malicious cert someone claims to have obtained from the manufacturer and tricks the user to install and trust. Such fake cert will not verify the device, but maybe the angle there the user might forget to clean up? I suspect it would be very hard for the malicious actor to find who trusts their fake cert in order to be able to exploit it.



  • Some customers told us there is a security issue if CA files show on support website. There is a rule internally, if customer wants new CA files, we need to apply with our PM one by one.

    Ultimately, you'll have to ask them, but I suspect that "some customers" don't understand PKI.

    To me, with just the context in the question, that seems like a totally legitimate request to have the manufacturing root cert so you can verify the devices on your network. To mitigate your own risk, you want to make sure you're getting the real CA cert and an attacker didn't intercept your email and replace the cert file on the way by. That could lead to malicious devices on your network that appear to be a SIP phone.

    The integrity of a root cert needs to be verified out-of-band before you add it to any trust store. I would open the cert file (for example in Windows Cert Viewer by double-clicking it), call the manufacturer's support and have them read you the cert fingerprint to make sure it's the same cert. Of course, if the cert was on their website, or the fingerprint was on their website, or the fingerprint was in their PDF admin guide, or something, then you would not need this step.

    The only possible risk I can see of posting their root cert is if their website is spoofed and a malicious version of the manufacturer cert is posted (containing the attacker's keypair), then someone could download it, install it to a trust store, and open themselves up to malware.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2