False positive: e_tls_server_cert_valid_time_longer_than_398_days triggered on qualified certificates with QSCD (eIDAS)

[lmgonzale-not]

ZLint is incorrectly flagging qualified certificates issued under eIDAS with a QSCD (Qualified Signature Creation Device) as violating the "validity period greater than 398 days" rule (e_tls_server_cert_valid_time_longer_than_398_days), even though these certificates are not TLS server certificates and are not subject to that limitation.

Our certificate is:

• Is qualified under eIDAS (0.4.0.194112.1.0)
• Is issued for electronic signature on a QSCD (0.4.0.194112.1.2)
• Is not a TLS server certificate – it does not contain serverAuth in its Extended Key Usage
• Not intended or used for TLS server authentication

And contains these OIDs:

• 1.3.6.1.5.5.7.11.2 → Qualified Certificate syntax v2 (PKIX)
• 0.4.0.194121.1.1 → Semantic identifier for natural persons
• 0.4.0.1862.1.1 → Indicates ETSI compliance
• 0.4.0.1862.1.4 → Indicates use of a Secure Signature Creation Device (SSCD/QSCD)
• 0.4.0.1862.1.6.1 → QCT for electronic signature

The Key Usage is Digital Signature.

We have other qualified certificates (under eIDAS) that are not issued via QSCD, and these do not trigger the e_tls_server_cert_valid_time_longer_than_398_days error in ZLint.

This shows that the issue appears specifically when the certificate includes the etsiQcsQcSSCD OID (0.4.0.1862.1.4), which indicates that the certificate is bound to a qualified signature creation device (QSCD).

These certificates are intended for qualified electronic signatures, not for TLS.

Thanks for your work on ZLint!

[XolphinMartijn]

@lmgonzale-not are you able to provide any existing certificates for reference and testing, perhaps some that you used for testing?

[lmgonzale-not]

@XolphinMartijn Thanks for your answer, I will send you some example certificates via email instead of posting them here. The subject of the email will be: "Zlint Issue 951 - Test certificates for ZLint issue with QSCD"

[defacto64]

It would be preferable to have those example certificates here, instead of shared in a private email exchange.

[XolphinMartijn]

It's not my place to share the samples that @lmgonzale-not sent out, but yes I agree, sharing them here would be best.

Looking at the samples: The leaf certificates didn't contain an EKU extension at all, which equates to "anyEKU", meaning TLS is in scope of the certificate. The cert doesn't have any of the cabf reserved OIDs though. It, and its CAs in the chain seems outside the scope of the TLS BRs, and with that, probably also outside the scope of the Apple root program, which is where this lint originates