It should be noted that there's nothing wrong with the certificates from a TLS or x509 point of view. The CA/Browser forum applies to CAs issuing publicly-trusted certificates that subscribe to those guidelines. Not all TLS or x509 use cases involve public trust.
An internal government or enterprise CA, for example, might reasonably choose to completely ignore these guidelines. In fact, if Chrome is applying those rules strictly to non-public certificates it's kinda contradicting x509v3:
In some situations, devices are given certificates for which no good
expiration date can be assigned. For example, a device could be
issued a certificate that binds its model and serial number to its
public key; such a certificate is intended to be used for the entire
lifetime of the device.
Obviously Chrome is under no obligation to accept such certificates, but they are a legitimate type of certificate nonetheless. An intranet user who wants to trust their own intranet CA (say, Active Directory) might find Chrome prevents them from doing so, based on requirements that are irrelevant to them because they don't subscribe to the CA/Browser forum.
It is incorrect to say that an x509v3 certificate is invalid because it has a long expiration date in the general case.
It is correct to say that an x509v3 certificate is invalid because it has a long expiration date when it is being issued by a ca which is expected to conform to the CAB requirements and is consumed by a user-agent which expected to conform to the CAB requirements.
It is therefore important to recognise that there's no intrinsic technical mechanism for determining whether a CA is supposed to be CAB conformant or not. Thus, browsers are left to either:
a) Assume the CAs subscribed to the CA/Browser Forum are conforming appropriately and accept false positives if the CA doesn't conform, for whatever reason.
b) Aggressively reject certificates that don't conform to the requirements in every case, regardless of who the CA is, imposing CAB-style requirements even where they might be actively harmful.
Neither is wrong, I think (unless there's a bit of the CAB that puts an obligation on the browser, I can't claim to have memorised the entire thing word for word - See addendum). What is correct is the SSL testers you've used don't reject the certificates as being inherently invalid. Without any context, it would be wrong to say they were invalid.
The outcomes you've described, then, is exactly what one might expect from these requirements and the answer to the question "Is this an issue with the certificate or a bug in Chrome?" is, in my opinion, the certificate, because it was issued by a CAB-forum subscribed CA that failed to implement their obligations in a non-ambiguous manner, forcing the browsers to make up their own mind about whether to enforce those obligations by veto or not.
Addendum:
The Requirements are not mandatory for Certification Authorities
unless and until they become adopted and enforced by relying–party
Application Software Suppliers.
Chrome (a relying-party Application Sof..... zzzz) have adopted and are enforcing it, thus by the letter of the law we can assert is mandatory for CAs that are dealing with publicly-trusted certificates and are subscribed to the CAB Forum requirements to create certificates that conform to this requirements.
(Unless we're being hyper-pedantic, in which case it's a plural and we'd actual need 2+ browsers to enforce it because otherwise Chrome is only a relying-party Application Software Supplier, not Suppliers.)
I think it's amusing that the obligations CAs are actually bound to changes depending on individual implementation details in every supplier. Any time a web browser or any software associated with the CAB anywhere in the entire world is updated suddenly a CA might have to implement a requirement that they didn't previously.
Thus, until it failed in Chrome, there was no obligation on the CA to conform. The moment Chrome was patched to start throwing this error, the CA was in breach of their obligations. Surprise, MF!
