My recollection of certificate linting goes back to 2016. Linting started happening to most public trust TLS certificates after three items came together.
So, what is linting?
I am not a software developer, so the term was foreign to me, but a quick search defined it as: “…the process of performing static analysis on source code to flag patterns that might cause errors or other problems.” The linting must detect specific problems to provide errors or warnings before moving forward. As such, the linting software could be written to analyze each certificate to see if it met the TLS Baseline Requirements, EV Guidelines and RFC 5280, as applicable
Linting, a brief history
In January 2015, the Certification Authorities (CAs) were required by Google Chrome policy to log all Extended Validation (EV) TLS certificates to certificate transparency (CT) logs. CT logs captured a real-time set of certificates from all CAs issuing EV TLS certificates. In addition, it also provided CT logs for all TLS certificates to be manually logged. The result was a resource of certificates to be reviewed.
Subsequent to the CT logging requirement, cert-search, also known as crt.sh, was launched. This web application allows people or applications to search all TLS certificates which have been CT logged. Cert-search also provided a growing list of tools to analyze the certificates.
Soon after, CA certificate managers struggled with how they were going to ensure their TLS certificates would meet all TLS Baseline Requirements, not to mention RFC 5280 (internet standards for certificate profile). The solution: Linting tools were created and published for open use through Github.
With everything in place, cert-search provided a 7-day real-time linting analysis of all TLS certificates. Here is an example using the cablint tool, https://crt.sh/?cablint=1+week.
By early 2016, the linting results indicated some certificate fatalities, and many certificate errors and warnings. This was really a name and shame game on all CAs which issued certificates not meeting the requirements. All CAs, browsers, auditors, and researchers could see if CAs had challenges when issuing TLS certificates. However, without any requirement for the CAs to review the linting results, the certificate problems slowly went away. Improvements were further increased when the CAs were required to log Domain and Organization Validated TLS certificates in CT effective October 2017.
Linting can also be deployed in a non-name and shame fashion, as it could be deployed by the CA directly as it issued its own TBS (to-be-signed) certificate, CT pre-certificate or TLS certificate. This would allow the CA to either prevent the non-complaint certificate to be issued or detect the non-complaint certificate in a short period after issuance. The CA can also extend the same methodology to other certificate types such as S/MIME, Code Signing and Verified Mark Certificates.
In a future blog, I will address how linting is being deployed in both the ecosystem and by Entrust. Until then, here are some linters to explore: certlint, zlint, pkilint and a tool to manually lintcerts.