feature request: nameConstaints support in Ziti PKI

[mrschyte]

Having nameConstraints support in the Ziti PKI would enhance security in case the CA certificate is leaked, since it could only be used to sign the subtrees of the specified domains.

I've tried to set this up manually by rebuilding the Ziti CA with the following extensions.

[ca_ext]
basicConstraints        = critical,CA:true
keyUsage                = critical,keyCertSign,cRLSign
nameConstraints         = critical,permitted;DNS:ziti.example.com,permitted;DNS:ziti.internal,permitted;DNS:localhost,
permitted;IP:127.0.0.1/255.255.255.255
subjectKeyIdentifier    = hash

In theory, this would allow me to host public ziti controllers and routers under .ziti.example.com and private routers under .ziti.internal.

This sort of works; the controller can be started and accessed via the API, however client identities cannot be verified, since they are generated with a common-name matching the identity id.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 338896 (0x52bd0)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, L = Example, O = Organization, OU = Unit, CN = Ziti Intermediate Certificate Authority
        Validity
            Not Before: Sep  3 11:46:40 2023 GMT
            Not After : Sep  3 11:47:40 2024 GMT
        Subject: C = US, ST = , L = Example, O = Organization, OU = Unit, CN = aiBod5iesh
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:

If the common-name suffix could be configured to match the permitted domains, I think validation would succeed.

I know this setup could be implemented using a 3rd Party CA setup, however I'd like to avoid that complexity.

[andrewpmartinez]

This has been moved to the security board for consideration.

Open Questions:

• what is the impact in an OpenZiti network when not having these as OpenZiti doesn't MITTM end-to-end TLS and does not alter or rely on OS certificate stores
• does the Go standard library support name constraints
• what kind of work is required in other libraries for C, Java, etc.

[mrschyte]

Thanks Andrew for the reply. I wanted to add some additional context to aid in the security boards discussion.

My reason for this feature request is that I would like to import the Ziti CA to end devices. Additionally, I think it would be neat if the Ziti CA could be used for creating TLS certificates for services (e.g. websites) hosted on Ziti.

Having nameConstraints enabled, would ensure that if the Ziti CA is leaked, only the ziti domain (e.g. *.ziti) can be impersonated. Otherwise the attacker could create certificates for "yourbank.com". I think with this feature even small users who don't have HSMs or other fancy tools for managing CAs would have peace of mind importing the CA.

[qrkourier]

Re *.ziti as a "private" TLD:

Here's a quick security side-note about TLDs in the root zone: It's safer and more useful to invent names in a zone you control in global DNS because it mitigates certain vectors.

Alternatively, ICANN reserved the INTERNAL TLD for private use. This means domain names like *.internal are to DNS as IP addresses like 192.168.* are to route tables, i.e., reserved for private use and will never appear in the root DNS zone ..

We shouldn't de-rail this GitHub issue, but I'm happy to discuss it further in Discourse: https://openziti.discourse.group/