5

I am developing an Internet of Things product and plan to use client certificate authentication, issuing each "thing" its own certificate on the production line so that it may authenticate with a central server. While this works well for our small trials where I issue and install the certs manually, I have a few questions before preparing to scale up for production:

1) Is there any benefit to using a "real" CA to issue my server cert and generate my client certs for me? The few I've found that do this are pricey, and while I'm no security expert, if I'm installing the client certs on the devices themselves, having a 3rd party doesn't really seem to provide any added benefit,

2) Is there some standard piece of software on the server-end that can capably handle authenticating tens of thousands of devices using an equally large number of certs? Can I simply stick each client cert in /etc/ssl/certificates and expect nginx, haproxy or something similar to be able to handle that? (we deploy between 30-50k "things" per year)

  • Are your certs only for use during the production-line (ex for grabbing firmware securely), or will they ship with the certs still on, and need the certs to be verifiable by any 3rd party? – Mike Ounsworth Dec 8 '15 at 18:53
  • The certs are issued at production time, but will be used to authenticate the client with the server for the life of the client (probably 3-5 years). I don't think they need to be verifiable by a 3rd party, as they will always used to communicate only with our servers, but that's what part 1 of my question was hoping to verify – AnodeCathode Dec 8 '15 at 19:08
4

If you want to keep your budget down, I would recommend you look into EJBCA which is open-source and free to use, though a lot of the fancy enterprise functionality is in their pay version. They make the following claims about throughput:

Since EJBCA uses standard relational databases, suitable for large scale and high performance you can easily scale EJBCA to hundreds of millions issued certificates, and with some care even billions. Depending on the architecture and interfaces chosen you can reach very low latency (sub 100ms) and very high throughput (>100 certs/sec). [source]

Though independent testing has found that this drops off pretty quickly when you get above 1 million certs issued.


Addressing the second part of your question:

Is there any benefit to using a "real" CA to issue my server cert and generate my client certs for me?

It really depends what you are using the certs for. I know that a lot of Internet of Things (IoT) manufacturing processes use client certificates to allow the devices to authenticate to the corporate network during manufacturing to do things like first-time config, firmware download, and other things that you want to do securely. At the end of manufacturing, those certs are destroyed / never used again. In the case it's perfectly ok to use a private internal CA that is hidden from the outside internet.

If, on the other hand, the certs you issue during fab will remain on the device into production and need to be publicly verifiable, then that's a different story. [For example, if you make lightbulbs, and you need users' iPhones to be able to verify that they are talking to an authentic IPBulb, Inc lightbulb, or the bulbs need to be able to authenticate to a IPBulb, Inc server to periodically retrieve updates.] In this case you will need to have a public-facing CA that does all the key-update and revocation status checking stuff. This gets complicated fast and it may be worth your while to partner with a commercial CA just to avoid the hassle.


EDIT: Pulling in the comments bellow to make the Answer self-contained.

My reason for advocating to outsource your certificate issuance is mainly due to server load and response times when you have to deal with revocation and certificate updates. For most small-medium companies, it's cheaper to outsource this to a specialist than to hire top-notch datacenter engineers.

Revocation: The tricky part is that the server that's verifying the certs needs to be able to ask the CA "is this cert still valid?" and get a response back very quickly (like < 25 ms). This is called the Online Certificate Status Protocol (OCSP). As your infrastructure grows, a single OCSP server won't be able to handle the traffic, so you now you need live database replication, and load-ballancers, and good datacenter engineers to keep the response times low. This is beyond the scope of most small-medium companies, and cheaper to outsource.

For certificate update / re-issue: There's no problem with the client dowloading its new/re-issued cert before the old one expires, but you have to have servers that are actively managing this, that have certificate management ports open to the public internet (potential attack surface / hacking point). Also, for ~30k certificates all expiring in a short time-period of each other, the server load will be huge. Again, how good are your company's datacenter engineers?

  • If my things will only ever authenticate with my domains (and no one else will be separately authenticating with my things) does a commercial CA add any benefit? – AnodeCathode Dec 8 '15 at 19:13
  • Hmm, that's right in the middle, isn't it? I guess you don't care about being able to revoke certs - which is where most of the complexity lies. Will you care about re-issuing certs that expire (assuming your products are still up and running in 5 years when their certs expire)?. If the answer to both is "no", then you may be able to side-step having a public-facing CA altogether. Lucky you! – Mike Ounsworth Dec 8 '15 at 19:16
  • I was under the impression that revocation could be handled on the server side (by removing the offending cert from the server's bundle, or something like that) -- is that not the case? Similarly, for re-issuing, while I don't necessarily think it will be an issue for us, why wouldn't it be possible to have the client download its new/re-issued cert before the old one expires? – AnodeCathode Dec 8 '15 at 19:20
  • Yeah, something like that. The tricky part is that the server that's verifying the certs needs to be able to ask the CA "is this cert still valid?" and get a response back very quickly (like < 25 ms). This is called the Online Certificate Status Protocol (OCSP). As your infrastructure grows, a single OCSP server won't be able to handle the traffic, so you now you need live database replication, and load-ballancers, and good datacenter engineers to keep the response times low. This is beyond the scope of most small-medium companies, and cheaper to outsource. – Mike Ounsworth Dec 8 '15 at 19:26
  • There's no issue with the client dowloading its new/re-issued cert before the old one expires, but you have to have servers that are actively managing this, that have certificate management ports open to the public internet (potential attack surface / hacking point). Also, for ~30k certificates all expiring in a short time-period of each other, the server load will be huge. Again, how good are your company's datacenter engineers? – Mike Ounsworth Dec 8 '15 at 19:28

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.