This is a partial offline conversation being brought online with follow up.
Original question: How are certificates stored on the OpenZiti controller? Are they in a vault? Is there any way I can define how long these certs should last etc? How and when to roll them?
Response 1: What do you mean with, “define cert validity”? Certs always expire but CAs are often set with multi year expirations.
The storage question would probably be directed at mop engineers, but right now it happens that the private keys (the actual sensitive file) are stored on the file system and expected to be protected accordingly with Linux permissions.
Response 2: For any CA there are three major validation points for any certificate:
For expiration there are authentication policies that govern whether expired certificates allowed or not. Currently defaults to true due to the fact that most of our deployed software for endpoints doesn’t extend their enrollment atm.
OCSP, CRLs, - long term gap that I was looking to close but I am getting priority signals that lower that work.
Documentation for Authentication Policies is sitting on this PR waiting to move forward: Edge Security Documentation by andrewpmartinez · Pull Request #149 · openziti/ziti-doc · GitHub
Response to question: “define cert validity”? Certs always expire but CAs are often set with multi year expirations.
When performing the validity of the certificate and its chain, what trusted root store do you use for the CA chain? Do you use the one built into the OS (e.g. windows cert store) or do you use one you maintain separately? If separately, how do you protect those certificates? Do you do more than cert path validation (e.g. expiration check, CRL check, certificate pinning)? Expiration and CRL answered below, but still looking to how the certificate store is maintained and secured.
Follow-up question related to private keys stored on the file system:
This is for the services. For the end user, besides support for pkcs11 tokens, is the users private key protected the same way as the server (e.g. operation ACL’s)?
Let me provide a bit more information for where I am going with these questions with regard to Ziti’s implementation of mutual tls.
The server side is less of an concern since it is in a “safe”er environment and the pki’s allowed by ziti are either built in or need to be authorized, so validation of the users certificate is likely to be fine. It will be interesting to see what validation checks are done on the users’ certificate but I think the answer has covered this.
• proper signatures - supported, required
• expiration dates - supported, optional configuration
• OCSP, CRLs - not currently supported, I started development on this
For the client side the environment is dodgier; it is far from a “safe”. Use of PKCS11 for the users’ private key is great as long as ziti is not caching its password anywhere statically. When not using a PKCS11 token one of the questions is to find how the key is protected. We assume this is defined by mbed tls? The other question for the client side is to determine how the certificate chain used to validate the server certificate is to be trusted. Does mbed tls have its own cert store or does it use the operating systems certificate store. If mbed has its own, how is that certificate store protected? How difficult is it to add additional certificates to that store? Does ziti use any method to not accept unwanted certificates from the mbed store (or the operating system) store even if they are valid certificates? Are the cert chain certificates simply stored by the ziti client in a file protected by ACL’s? Does the client software support trusted root certificates via PKCS11?
mbedTLS does not have its own store, mbedTLS SSL context is configured from Ziti Identity file.
Ziti client identity is stored in a single file that contains both identity’s key and cert and controller CA chain. the security of the file is generally left to the deployment – i.e. proper file ACL protection should be configured.
Ziti identity file is created during enrollment, with the following process:
At the moment we only use PKCS11 for private key storage (in step 3 above, existing private key can be used, either from a file or PKCS11 driver)