Questions about edge-client certificate extension

Support General Questions
1

I have a couple of questions about edge-client certificate extension:

  • Assuming the client certificate is managed by Openziti, do the Openziti tunnellers currently extend client certificates automatically?
  • What is the correct procedure for extending a 3rd-party client certificate? I understand that the new certificate would be obtained from the CA. However, when replacing it on the client do we need to perform any manual steps (like updating an authenticator)?
1 Like
2

Hi @plakdawa. Welcome to the community and to OpenZiti!

Currently, by default, client certificate expiration is not enforced. You can change the controller to enforce client certificate expiration time, but it's not enabled by default. As such, the edge clients do not extend their certificates at this time.

With a third-party cert, if you use an external-id, then all that matters it the cert is signed by an appropriate ca and contains the expected claim. So you'd just replace the cert, ensure the same claim, and there'd be no problem. You'd have to restart the client, most likely. I expect all the tunnelers do not monitor identities at this time. I could see that changing in the future perhaps, but that's how it is right now, I believe.

1 Like
3

Thanks @TheLumberjack for the quick response.

Does this mean that we must use an external-id with an identity when using a 3rd-party CA? Is there a way to avoid it, if we prefer to use the default authenticator?

I can see a situation where we use the certificate as the first-factor for authentication and a JWT from an external JWKS signer as the second factor. Since an identity currently supports just one external-id this would mean that the two factors would have to have a common attribute to match (which may not be possible).

1 Like
4

No you don't need to. If you enroll the 3rd party ca though, and change it, I do think the fingerprint changes and the enrollment would need to be updated to reflect the new fingerprint but to be entirely frank, I actually don't know. I've never expired a cert for client auth in this way. I was trying to provide a way that would be easy to accommodate rolling the certs. I'd have to defer to someone else who might have either done this in practice or who knows for sure. Your scenario makes perfect sense, yeah. I would say in that situation, I'd not enfoce the cert expiration and instead leave the time-based aspect to the JWT, perhaps?

I'll try to get @andrew.martinez to comment to see if there's more nuances here, he spends a lot more time thinking about these things than I do. :slight_smile:

1 Like
5

Certificate authentication requires that an x509 certificate is matched to an identity. There are two main approaches to do this:

  1. fingerprint matching (hash of the raw cert bytes compares)
  2. x509 claims (matching some data in the x509 certificate to an identity's external id)

When OpenZiti issues certificates are used, only fingerprint matching is used.

If certificates are being issued by a 3rd party CA and fingerprint matching is being used, it is up to whoever is managing the certificate life cycle to update the fingerprint in OpenZiti. This can be done via re-enrollment indirectly or via the Management API by doing an PATCH/PUT to /authenticators/<id> and providing the certificate.

To avoid having to manage the certificate fingerprint for 3rd Party CAs (i.e. in environments that use fast rolling certs), x509 claims can be used. x509 claims allow an externalId to be described on an identity and additionally be described in x509 certificates.

1 Like
6

@andrew.martinez thanks for the details.

I am still unclear around the mechanics of client re-enrollment when the certificate is 3rd-party managed:

Is that possible from the edge-client API? Or is this process reserved for edge-clients certificates that are ziti managed? The docs don't seem to be clear about this:

7

No when working with 3rd Party CAs.

The Client API doesn't allow the direct management of certificates. Direct manipulation of certificate authentication configuration is considered management action and only exposed in the Management API for use by administrators.

The Client API allows indirect management of certificates through the enrollment process and extension process only. The extension process only works for the internal OpenZiti CA as it use a CSR based process which requires access to a signing CA's private key.

When using 3rd party CAs, you are taking on the responsibility of issuing and managing the certificates. This involves the entire lifecycle of the certificates as well as managing the registration of them with OpenZiti. If certificates are short lived or you want to alleviate the need to register new certificates, I suggest using x509 claims.