I have the following scenario:

  • Several independent embedded servers (Linux/ARM/lighttpd)
  • Several independent controlling devices (win32/iOS/Android)
  • Each server should have at least one controlling device
  • Each controlling device can control one or more servers
  • None but the controlling devices should be able to contact servers

I understand I could use Client Certificates to ensure "device/server pairing", but I am unsure if at all possible and (eventually) how to setup my systems to fulfill the following additional requirements:

  1. Hassle-free Client Certificate installation: I mean I would like to have some automated procedure initiated on the server (possibly via physical push button) which will create and deploy a specific Client Certificate (something akin to "Wi-Fi Protected Setup").
  2. Role-based certificate creation: each controlling device should have a "role", meaning it can perform a defined set of operations on the server; essentially I need just to embed some data in the certificate at creation time.
  3. Client Certificates should be expiring and revocable (I think this is standard, but must be allowed-for while creating the certificate itself).

Real question is how to setup (1), where I have little clue. I have searched the Internet, but I found only the "normal" way (generate cert, self-sign, manually import into browser) which is way too complex for my Customers :( ; I was hoping to be able to generate a URL (or print a Qr) that, entered on controlling device, would "automagically" configure its browser (possibly with just some simple "OK" confirmation). Is this (or something equivalently dumb-proof) possible, somehow?

Advise and comments on the other issues are welcome (of course!)

NOTE: I am not requiring bank-proof security, just a reasonable compromise; focus is on how much I can achieve "without bothering users" (entering a password is considered bothersome, unfortunately).

  • I think what you want is Autoenrollment. Unfortunately I don't know anything else about that. Dec 21, 2015 at 9:50
  • @StackzOfZtuff: I seem to understand autoenrollment is used (on Linux) to deploy self-signed Host Certificates (partial implementation of the Win procedure [e.g.: rickygao.com/…). Did I miss something?
    – ZioByte
    Dec 21, 2015 at 10:10
  • Dunno. But the idea of autoenrollment is that you don't have to use self-signed certs. Dec 21, 2015 at 10:16

1 Answer 1


I'been digging in the Certificate field recently, and I know it's been a month since you asked, but I hope this helps you some way.

In order to give each of your customers a certificate, You'll basically need a server with its own selfsigned Certificate. This server will "give" your customers their new Certificate. The flow would be something like this:

1) [FRONTEND] The customer generates a keypair and sends the public key to the server, asking for a new certificate.

2) [BACKEND] The server generates a new certificate based on the customer's public key, and sends it back to the customer with a specific header saying it's a certificate.

3) [FRONTEND] The customer "download" the certificate, the browser knows it's a certificate and prompts the customer to install it on the browser with just a click.

For (1), there are ways to do it with just a click. For most browsers you can use the "keygen" html tag, for IE sadly you have to use ActiveX. For (2), you'll need some kind of CA Management module, there are some free ones out there, like OpenCA or EJBCA.

It could be a little hard to implement, but it gives an undoubtable authentication for your customers, as they are using certificates signed by you, and it's really pretty easy on the customer side, it doesn't need more than a 2 or 3 field form and two clicks.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .