bugfix: Added base key validity period of 60 minutes.

[ishanjain28]

• read the CONTRIBUTING guidelines
• raised a GitHub issue or discussed it on the projects chat beforehand
• added unit tests
• added integration tests
• updated documentation if needed
• updated CHANGELOG.md

Fixes #764

PR Description,

Currently headscale initializes machine key's expiry time with &time.Time{}. This is formatted to, 0001-01-01T00:00:00Z(in RFC3339 format).

This means, The keys expiry time will always be in the past and clients will be stuck in a loop renewing the key.

This PR addresses this problem by adding a minimum validity of 60 minutes to the generated keys.

[ishanjain28]

This issue has not been fixed completely.

Android clients are working fine and are getting the correct expiry time but Linux clients are still getting,

expiry | 0001-01-01 05:53:28+05:53:28

[ishanjain28]

Fixed.

1. OIDC renewal code mentios that the function accepts current time but then passes, &time.Time{}. This has been changed to pass, time.Now().Add(DefaultKeyExpireTime).
2. In protocol_common.go, In the refresh operation it was not renewing the key. expire field in database was being overwritten to 0001-01-01T00:00:00Z.

[juanfont]

Comment should end in a period

[juanfont]

Comment should end in a period

[juanfont]

Suggested change

## 0.17.1 (2022-XX-XX)

[juanfont]

Can you please add this under 0.17.0 ?

[juanfont]

Any rationale behind 60 minutes?

[juanfont]

Digging into this, upstream only seems to say about key expiration this (in RegisterRequest)

// Expiry optionally specifies the requested key expiry.
// The server policy may override.
// As a special case, if Expiry is in the past and NodeKey is
// the node's current key, the key is expired.

Perhaps could be DefaultKeyExpireTime could be something configurable, with a default time of 60 minutes...

[kradalby]

Hi! as part of #1473, we have reorganised a lot of the code.

To clear PRs that needs to be rebased or redone, we are closing open PRs that will require significant code change to be merged.

In addition, the issue of the PR might in some cases have been fixed, change or no longer relevant, so it would be great if this is considered as well.

Thank you for your contribution!

If it is still relevant and the PR is reopened, we will aim at getting the changes into the next release after the reorg if accepted.