We would like to limit access to our web servers (and eventually other services on the computer) to individuals that have been authorized access. Of course we don't trust passwords so we think certificates are the right answer.

There are hundreds of these servers. Access to any one server should NOT provide access to any other server. The access should be to only the single server. (Access will also be time-limited for additional security).

Other relevant requirements

  • The server is remotely installed and may not have good or any internet access.
  • The server should be capable of stand-alone operations (ie not relying on much external infrastructure)
  • Other protocols will be involved besides HTTPS (e.g. MQTT). Features that require specific support from servers may be difficult.
  • The server will be accessed by attaching a computer to a port directly on the device. (Ie Internet (or intranet) optional).

How can we implement these security requirements?

We are currently on a path that would involve creating individual CAs for each server. The server would require mutual authentication for the server and client. The server and client certs would be signed by the unique CA for each server.

Added "Why 1-1"

Why 1-1 CA to Server?

The fundamental behavior of certificates is trust. Any certificate signed by a trusted CA is likewise trusted.

Consider two server certificates are signed by the same CA. If a user (client?) certificate is also signed by the same CA then that certificate can be used to authenticate to the either server. The requirement is that the user is only authorized to access one server, not the other.

Is there additional information that can be included in a user certificate that would further enforce the use of the certificate for a single server and rejection on any another server?

I've seen that additional information can be added to the certificate. Is there something inherent to certificates that allows enforcement that the certificate is only useful to one server?

Is there an alternative? Perhaps one that does not involve creating many CAs?

FYI -- The servers are all running Linux.

  • 1
    What is your threat model? Jul 17, 2020 at 23:30
  • Why is your conclusion that you must have 1:1 ration of server to CA?
    – schroeder
    Jul 18, 2020 at 7:19
  • @ schroeder I'll add that information to the question. Jul 19, 2020 at 17:08
  • You have not explained why your design requires 1:1 CA:server. And no, just because a client certificate is signed by the same server, that does not mean that the certificate grants access to everything ever signed by the same CA. I think you have some unexamined assumptions there or you have not explained all your context.
    – schroeder
    Jul 19, 2020 at 17:40
  • If I get a client cert signed by Comodo, that does not mean that I am automatically granted access to any server that also has a certificate signed by Comodo.
    – schroeder
    Jul 19, 2020 at 17:42

1 Answer 1


This can be simplified with some form of central management, such as using a directory/identity server that speaks LDAP or another protocol. This would only require a single CA in the ecosystem, and it prevents you from needing to set up access controls on each server individually.

On the directory server, each user is added, along with their public key and possibly groups that correspond to the servers they should be able to access.

When a client connects to a particular server, the web server (e.g. Nginx) initially checks that the user's certificate is signed by the CA. If the certificate is valid, the certificate's information is extracted and passed to the application. Then, the user can be looked up in the directory server, and their privileges/groups returned. Then, the server can check if the returned groups should be granted access, and proceed from there.

You can easily revoke access from the directory server to prevent further usage of the certificates.

Of course, implementing this will depend on your specific application and what tools you are willing to use. There may even be a ready-made solution out there.

  • Thanks for the suggestion. We will add this to the possibilities. I added other relevant requirements that conversations like this help to make clear. The requirements are burying me into a corner. Jul 18, 2020 at 0:24

You must log in to answer this question.

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