Protecting Ziti Certificate Authority certificates

Ziti Overlay
1

As I make my way closer to a production implementation, I find new things that I need to have a clearer position on.

The current issue is the location of the certificates that are required for an OpenZiti controller, along with the edge/fabric routers.

For user end points, my understanding is that its best to use some type of credential manager. This could be a vault for server endpoings, or a keychain for client endpoints.

However, I am unsure what is the best practice for the controller, edge routers and fabric routers.

I realised that I needed to know more information when I started to investigate the following three common types of DNS attacks:

  1. poisoning attacks
  2. take over an authoritative DNS servers
  3. compromise the registration of the domain itself

Hence, I thought to ask for some guidance around this. Specifically, how you store and manage your certificates for the controller and routers to minimise such an attack.

At this point, the main thing I know is that you no longer need a private DNS if you have app embedded ziti… as there is no intercept. Removing this is a big win, but you still need a DNS if you want to integrated with non embedded applications.

Also, when you are using a private DNS, you need to have strong internal controls around how the controller and routers certificates are protected. It needs to replicate the same types of controls that would be used to manage public DNS certificates.

One of the other topics I am also keen to learn more about is SPIFFE… as I also believe this to be a great way to extend protection… in a simple and practical manner.

Let me know if you have any tips to point me in the right direction.

2

We don't quite have a "from quickstart to production" guide yet. In general, I would think that you are best off running the ziti processes as non-root users and only granting the users the minimal amounts of capabilities they require (which will be documented in that "from quickstart to production" we don't have published yet). After that you would use linux itself to secure the filesystem properly and only allow this user access to the certificates/configuration.

1 Like
3

Thanks… I am getting my head around a lot of extra stuff… and thought to just check in that I was heading in the right direction.

Great insights.

Keen help out more if you need more arms and legs for a “quickstart to production” guide… I believe this would be very valuable… especially when you want to integrate other public certificates to avoid the browser warnings when you use self signed certificates etc