It produced a .json file? That definitely surprises me, I'm certain I have had JWTs expire in the past. I'll test it out locally to see what happens as well.
the ziti CLI will check the token before attempting to enroll the jwt and will refuse to attempt to enroll the JWT reporting:
ziti edge enroll c:\temp\expired-jwt\ziti-id.jwt
Usage:
ziti edge enroll path/to/jwt [flags]
Flags:
--ca string Additional trusted certificates
-c, --cert string The certificate to present when establishing a connection.
-h, --help help for enroll
-n, --idname string Names the identity. Ignored if not 3rd party auto enrollment
-j, --jwt string Enrollment token (JWT file). Required
-k, --key string The key to use with the certificate. Optionally specify the engine to use. supported engines: [parsec]
-a, --keyAlg RSA|EC Crypto algorithm to use when generating private key (default RSA)
-o, --out string Output configuration file.
-p, --password string Password for updb enrollment, prompted if not provided and necessary
--rm Remove the JWT on success
-u, --username string Username for updb enrollment, prompted if not provided and necessary
-v, --verbose Enable verbose logging
failed to parse JWT: token has invalid claims: token is expired
Assuming @andrew.martinez agrees with the implementation, we'll file an issue with the ziti-tunneler-sdk-c repo to do the same thing as the ziti CLI.
It would seem to me that the controller should also block this enrollment attempt (since it knows that the client JWT has expired)? Or am I mis-understanding the flow?
All enrollment clients should verify their JWT isn't expired before using. The JWT is used for trust relationship building, so using expired ones, is not something we should do.
The controller, no matter what, should also not be allowing expired enrollments. There is currently a disconnect between the enrollment and the minted JWT in terms of expiration.
I have already submitted a fixes and tests for this case and related cases.