How important is local time for security?

You have a bunch of questions rolled in there.

I guess NET::ERR_CERT_DATE_INVALID means that an HTTPs certificate is not valid.

Yes.

Here is the cert for help.ubuntu.com:

You'll notice that it has Valid From and Valid Until dates; if you try to access a site protected by this cert outside of these dates, your browser will complain. The reason certs expire is (among other reasons) to force webmasters to keep getting new certs using the latest crypto and other new security features in certificates.

When your browser is trying to decide if it trusts a certificate, it uses the system clock as the definitive source of truth for time. Sure, it'll try to use NTP, but if you (the admin user) have explicitly told it that the NTP servers are wrong, well, you're the boss.

---

If an attacker can arbitrarily change the system time, which kinds of attacks allows this?

Let's consider personal computers and servers separately. I haven't done any research here, just off the top of my head.

Personal Computers

• Users often play games with their system clock to get around "30-day trial" type things. If you're the company whose software is being used illegally this way, then you would consider it a security issue.
• Spoofed websites. It's much easier to hack old expired certificates -- maybe it used 10 year old crypto that is easily cracked, or maybe the server was compromised 6 years ago but the CAs don't track revocation info for that long (idea credit: @immibis' answer). If an attacker can change your system clock then you won't see the warnings.

Servers

• Logging. When investigating a security breach, if your servers' clocks are out of sync, it can be very difficult to piece together all the logs to figure out exactly what happened and in what order.
• Logins. Things like OTP 2 factor authentication is usually time-based. If one server's clocks are behind a different server, then you could watch someone enter an OTP code, then go use it against the server that's behind because that code won't have expired yet.

One reason is that certificate revocation records are not kept after the certificate expires.

Suppose I stole Google's certificate 10 years ago. Google immediately noticed and revoked their certificate. Since the certificate expired some time in the last 10 years, the revocation entry was deleted. If I set your clock back 10 years to when it was valid, I can impersonate Google and your browser won't notice, because it won't know it was revoked.

Your question is broad, but if an attacker can change the local system clock, then they can poison the logs of their activity. That way, they can hide their activity to appear to have occurred sometime in the past (and maybe beyond the window that the admins are looking for activity) or to coincide with other user's activity.

For example, if you break into a system in the middle of the night, you can set the clock to be at noon the previous day, do your activity, then set the clock back. Anyone inspecting the logs will assume the normal user did the activity (or not see it at all among the normal user's activity).

This is why setting your clock to be synced with an authoritative external source is important. That, and that all logs from all sources can be properly correlated.