Openziti installation in production like environment

Thank you for doing that. It captures the question perfectly.

I did get auto-enrollment working with OpenZiti where a certificate from a third party CA (Windows) was used to autoenrol the identity into openZiti. This worked as expected. However, getting there was a mission and not, what I would say was repeatable, or ready for production deployment.

I did have some questions on this thread: https://openziti.discourse.group/t/3rd-party-ca-problems-questions/592/7 .

Basically it got too hard for a number of reasons which I have put in Github issues in help reduce the friction ( Support for Windows certificate store Ā· Issue #550 Ā· openziti/desktop-edge-win Ā· GitHub), Natively import .pfx (PKCS #12) certificates Ā· Issue #549 Ā· openziti/desktop-edge-win Ā· GitHub.

I decided that I would just go with the built in CA and let it that handle the renewals etc. Sending someone a jwt token to enroll is far easier than

a) Create a cert for the user/machine (Windows CA) (because it cannot reach into the Windows Cert store)
b) Having OpenSSL binary somewhere to extract the .key and .crt files from it (Github enhancement to import direct) as the cert comes as a bundle
c) Downloading the ziti command separate package to get the identity installed because ziti-edge-tunnel enrol does not work ( Unable to import identity through ziti-edge-tunnel Ā· Issue #548 Ā· openziti/desktop-edge-win Ā· GitHub)
d) Then would need a check script for when the cert was expiring to replace it.

That was what I found.

Thank you for the reply @gooseleggs

Fortunately our current setup has solved those problems up to certain extent. ( hosts are bootstrapped with identity from internal CA with cert and key in pem format, cert is rotated daily with an optional key rotation ).
Great point about possibility of having to ship ziti cli in addition to ziti-edge-tunnel, but i havenā€™t got that far yet.
And we are still exploring usage of hardware enclaves to store key material.

For Edge Routers - the only thing you can do is specify the private key. During enrollment, if the private key exists (inline PEM, file PEM, or HSM via PKCS#11) in the configuration, it is used in place. The certificates and CSR process is currently a closed loop beyond that.

I'm trying to enroll a new edge router, on a separate node, and it tells me it can't open the private key. I thought the enrollment process created the key. Did I miss a PKI step somewhere?

gormami@dell640:~/.ziti/quickstart/ziti-bin/ziti-v0.27.1$ ziti-router enroll ~/ziti/config.yaml -j ~/ziti/KendaleRouter.jwt
[ 2.454] FATAL ziti/ziti/router.enrollGw: enrollment failure: (could not obtain private key: open ~/.ziti/config/certs/192.168.0.124.key: no such file or directory)
gormami@dell640:~/.ziti/quickstart/ziti-bin/ziti-v0.27.1$ ll ~/.ziti/config/certs/
total 8
drwxrwxr-x 2 gormami gormami 4096 Dec 31 13:53 ./
drwxrwxr-x 3 gormami gormami 4096 Dec 31 14:15 ../
gormami@dell640:

Two things but I think itā€™s the first one thatā€™s the problemā€¦

  1. I donā€™t think tilde expansion will work like this in golang. Thatā€™s a shell feature, and Iā€™m not sure itā€™ll work when used in the config file.
  2. Also make sure the ~/.ziti/config/certs/ exists. If the folder doesnā€™t exist, I donā€™t think the enrollment process will create the folder for you (but I think itā€™s the first issue thatā€™s the problem)