I want to build a distributed software system with the following elements:

  • A number of workers, which manage potentially sensitive data and execute code on behalf of a number of clients.
  • A number of clients, which can send commands to the workers.
  • A central trust authority, which grants the right to execute actions on a given worker to a client.

In a typical operation, the client would contact the trust authority and request the authorization to execute an operation on a worker. The trust authority would authenticate the client and -if it succeeds- grant the authorization. The client would then connect to the worker server and issue the requested command, presenting the authorization that was obtained before. The worker server would be able check the validity of the authorization for the requested operation and -if it succeeds- perform it.

X.509 seems like a natural fit for this kind of problem, and the simplest solution I came up with looks like this:

  • The trust authority uses a X.509 certificate to hand out authorizations to clients, signing them with the private key of the certificate.
  • The client transmits the signed authorization from the trust authority to the worker server.
  • The worker server downloads the public certificate from the trust authority's server and uses its public key to validate the authorization provided by the client.

To implement this, I would provide a HTTPS-based REST API on the trust authority server. Using this API, the worker server could download the public key certificate and locally validate it against a higher-level certificate (if it was signed by a CA). Using the public key obtained in this way the worker could then validate an authorization received from a client.

To obtain an authorization, a client could use another API endpoint on the trust authority, to which it provides all relevant details of the given command and worker server. The trust server would then respond with a signed authorization that the client can pass on to the worker server.

(in all of the steps above I assume that the communication between all parties can be secured and validated using some form of TLS)

My question regarding this setup is threefold:

  • Is this a reasonable approach? If not, what would be?
  • Against which possible attack scenarios would this scheme be vulnerable?
  • Are there any open-source reference implementations of such a system?
  • 2
    Your design is already very specific in that you want to use X.509 certificates and a HTTPS REST API. But the basic idea of a client authorizing against a central server which then grants tickets to allow specific actions can already be found in Kerberos which is also the base protocol of Active Directory in Windows. Commented May 13, 2017 at 14:29
  • Thanks for the link, I was wondering if it would be reasonable to use an existing crypto library to implement a scheme like this, or if it would be better to use an existing solution (I also want the system to be as simple as possible). Commented May 13, 2017 at 14:52
  • JWT (en.wikipedia.org/wiki/JSON_Web_Token) matches many of the requirements I have btw, but I wondered if there is something simpler / less geared towards HTTP. Commented May 13, 2017 at 15:04

1 Answer 1


x509 is a file format not an application architecture.

It's far from clear what you are asking or intending to actually build here. A HTTPS webservice using client certificates is not exactly innovative nor even esoteric. Certainly if you are expecting to build your own cryptographic capabilties I would strongly recommend you to think again - these are available off the shelf but are extremely difficult even for experts to implement correctly.

Most open-source software is components rather then complete distributed infrastructure patterns.

Assuming that you just want a HTTPS webservice using client certificates, then the server part would take around an hour or so to set up using (for example) Apache, mod_ssl and a suitable logic tier. What consistutes a suitable logic tier depends on where you want to implement authentication and authorization. If this is done in Apache (with SSLOptions +SrdEnvVars), then any old scripting language will do (indeed you could even use stunnel or stud in front of a generic webserver rather than mod_ssl inside Apache).

For testing - stunnel or stud provide an easy way to wrap connections using TLS and client certs (assuming you don't want to just use a browser)

In terms of generating a "signed authorization", again this is simple - but is there a reason for implementing a secondary authorization mechanism on top of the facilities available within TLS/x509? If you can reliably authenticate the client and the trust authority, then either embed the authorization in the client cert or just provide mappings of identity to authorizatoins to the agents from the trust authority.

  • Thanks for this answer, I'm not sure if you understood my question though: I want to have a system with three parties, where X.509 certificates would be used to establish trust and authorize specific operations between two of the parties using a signature provided by a third party. I do not intend reimplementing anything from scratch, hence my question if this is a reasonable approach and/or if there are any open-source applications/libraries available for this purpose. In my question I also stated the assumption that the communication is secured via TLS/SSL already. Commented May 13, 2017 at 14:49
  • 2
    What you describe sounds like kerberos ticketing - but if you are using TLS with client certificates then you are using a different authentication model than kerberos and hence the ticketing system is mostly redundant.
    – symcbean
    Commented May 13, 2017 at 22:02
  • Thanks for that info, another poster already mentioned Kerberos as well, will have a look into that. In principle I think I want something similar to JSON Web Tokens (JWT), which in my understanding are implemented via simple RSA-based signatures using a private/public key pair. I'm just wondering if it would be "good enough" to use a system that makes use of RSA certificates to sign/verify messages (e.g. via the "cryptography" Python library) and uses a secure channel to distribute certificates, or if there are any pitfalls that would make it more reasonable to use an already existing system. Commented May 13, 2017 at 22:51
  • I would just want to avoid setting up a complex system like Kerberos if there's a simpler alternative that provides similar security guarantees for a very simple use case. Commented May 13, 2017 at 22:55

You must log in to answer this question.

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