Wrong certificate Timestamp registered on the server during node setup

Icinga 2
, ,
1

Hello,
I have a problem with the node registration on the icinga server using ‘icinga2 node setup’.
We noticed some strange Timestamp on the server for some certificates.
After some analysis I discovered the Timestamp is provided by the client which is wrong for us and may be due to, for example, hosts reinstalled after a long period down with a clock drift (there’s a ntp configured but it’s updated long after the icinga module is executed).
As we are using this timestamp in our processes to validate hosts it creates some unexpected behavior.
Is it a bug or a feature and if so, is there a way to change this behavior and have the Timestamp field using the the Icinga server time?

Example:
in the following example I configured the date on host myhostname with April the 16th (two days in the past), then I run the icinga2 node setup and checked the result on the server:

Fingerprint Timestamp Signed Subject
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Apr 16 10:55:54 2025 GMT CN = myhostname.mydomain

[icinga@server]$ date
Fri Apr 18 10:56:27 CEST 2025

Current date on the server is we are April the 18th, so the time displayed is the one from the client which makes no sense to me (or maybe I’m not seeing the whole thing :wink: ).

Thanks in advance for your help
Max

  • Version used: r2.14.5-1 (on both client and server, issue was already present with previous releases)
  • Operating System: Debian 11.5 on client side, RHEL 8.10 on server side
2

The standard certificate signing request using icigna node setup is always created on the node.
The signing request is than forwarded to the ca for signing.

If your node has the wrong date, your signing request has this date too.

You can check again the dates after the certificate is signed, idk if the icingaca corrects the date or not.

2 Likes
3

While @moreamazingnick has already said everything relevant, I wanted to add that having synchronized clocks are important for Icinga, especially between two master nodes, but also for normal nodes. So I would recommend you to always configure NTP and monitor it, e.g., by check_ntp_time.

2 Likes