🐛 BUG: overall poor behavior with "not before" field in host certificate

[lostmsu]

What version of nebula are you using? (nebula -version)

1.8.2

What operating system are you using?

Windows

Describe the Bug

Repro steps:

• sign a host certificate
• rollback time a little bit
• try to start nebula client

Expected:

Some reasonable behavior, e.g. one of the

• no error because small time drift is mitigated by nebula-cert setting "not before" to a few minutes prior to now
• if "not before" is in the future some short interval away from now, nebula prints a warning, waits for "not before", then resumes connection
• nebula returns a descriptive error message (preferably machine readable so the invoker can figure out "not before" value) and exits with some specific error code

Actual:

• client exits claiming certificate has expired

Logs from affected hosts

error="nebula certificate for this host is expired"

Config files from affected hosts

Nothing special

[johnmaguire]

@lostmsu NotBefore is a standard certificate criteria. Allowing for time drift sort of defeats the purpose of it, IMO. We expect clocks to be properly timesync'd. This is also why it's listed as a dependency in the example service file.

What's the use case for creating a certificate and then rolling back the system clock, as in your reproduction steps? Or, how are you encountering this problem in the real world?

[lostmsu]

@johnmaguire in the real world the CA is on a different machine. I suppose the time it takes to generate certificate there, copy it to the client, and launch nebula is just shorter than the small time difference between the machines.

Allowing for time drift sort of defeats the purpose of it, IMO

That's why I suggested two other options.

BTW, generating a certificate with NotBefore configurable to past might be needed not only because client won't start if its time is slightly behind, but also I am not sure what happens if client is up to date, but the node it is trying to connect to is slightly behind.

Basically, I want to be able to have some reasonable grace period. E.g. when I say duration of the certificate is 24h, I don't see why NotBefore can't be -1m.

Just checked time drift on a few of my PCs and it ranges from -25ms to almost +2s.

[johnmaguire]

@lostmsu Understood. We're investigating allowing users to specify overriding the NotBefore at signing time.

That being said, in the meantime, enabling NTP on your machines should resolve time drift.

[lostmsu]

@johnmaguire it is not as simple as that. The machines I ship certificates to are customer's machines, some of them Windows. Not even domain joined.

[johnmaguire]

Thanks Victor, that's the real world scenario I was looking for. This context is helpful when determining the best solution. :)