Client certificate can be refused due to minor time difference causing `The provided certificate isn't valid yet` error

[simondeziel]

During a CI run, a remote join token was apparently created with an "Not Before" date that was in the future (dunno how far off):

++ lxc exec target -- lxc config trust add --name host --quiet
+ token=eyJjbGllbnRfbmFtZSI6Imhvc3QiLCJmaW5nZXJwcmludCI6IjdhYmY1M2UwNjM4MTRkYmNlNTRlZTM5YTUzYTNlMWNhYzdkYTYxN2M2OTMwZjZjNGIxMzNjY2IyZTg3YTg0MzMiLCJhZGRyZXNzZXMiOlsiMTAuMTE4LjEwNC4xODI6ODQ0MyIsIltmZDQyOjQ4ZWM6ZWJjNDpiMjM5OjIxNjozZWZmOmZlM2I6MzdmN106ODQ0MyIsIjEwLjE1MS4xMjkuMTo4NDQzIiwiW2ZkNDI6NDRjNDo1NzA0OmVhOWM6OjFdOjg0NDMiXSwic2VjcmV0IjoiMzFjMTRiMmI5NDNkZDEzMDU5NGE5MGEwZmM0NGNkNzhiNmVhY2JmMWVmNTAxMWJhOGIxODVlMzAyODYwZjIzMyIsImV4cGlyZXNfYXQiOiIwMDAxLTAxLTAxVDAwOjAwOjAwWiJ9
+ lxc remote add target eyJjbGllbnRfbmFtZSI6Imhvc3QiLCJmaW5nZXJwcmludCI6IjdhYmY1M2UwNjM4MTRkYmNlNTRlZTM5YTUzYTNlMWNhYzdkYTYxN2M2OTMwZjZjNGIxMzNjY2IyZTg3YTg0MzMiLCJhZGRyZXNzZXMiOlsiMTAuMTE4LjEwNC4xODI6ODQ0MyIsIltmZDQyOjQ4ZWM6ZWJjNDpiMjM5OjIxNjozZWZmOmZlM2I6MzdmN106ODQ0MyIsIjEwLjE1MS4xMjkuMTo4NDQzIiwiW2ZkNDI6NDRjNDo1NzA0OmVhOWM6OjFdOjg0NDMiXSwic2VjcmV0IjoiMzFjMTRiMmI5NDNkZDEzMDU5NGE5MGEwZmM0NGNkNzhiNmVhY2JmMWVmNTAxMWJhOGIxODVlMzAyODYwZjIzMyIsImV4cGlyZXNfYXQiOiIwMDAxLTAxLTAxVDAwOjAwOjAwWiJ9 --accept-certificate
Generating a client certificate. This may take a minute...
Error: Failed to create certificate: The provided certificate isn't valid yet

A potential workaround would be to be a bit more forgiving and set the "Not Before" date to now - 1m?

[tomponline]

The test has a comment:

Add the target VM as a remote LXD

So i dont think its related to container namespaces, but rather clock synchronisation between the 2 VMs. Can we run a forced time sync before the operation?

[simondeziel]

@tomponline thanks catching that this is using a VM despite the script name being container-copy :/

As you suggested, I'll add a short loop to ensure the VM's time has sync'ed before requesting a token, thanks and sorry for not taking a closer look.

[simondeziel]

I've clarified the issue description now that I better understand the issue. The issue isn't with the token itself but using tokens exacerbates the issue.

The problem requires some conditions to happen:

1. The remote has to be in the past compared to the client
2. The client must not already have an existing client cert

Then, when the client consumed the remote token, it creates a fresh cert on the spot and send it to the remote along with the temporary/single use join password to trust the cert. The join password matches but the remote refuses the client cert as its "Not Before" date is in the future.