In a previous blog we introduced Digital Certificate Linting. It is interesting how certification authorities (CAs) have deployed certificate linting of public trust certificates without policy requirements from the browsers or the CA/Browser Forum. Linting does not need to be mandated as it naturally helps CAs to be compliant by limiting certificate miss-issuance. This also increases customer service as certificates do not need to be revoked and reissued.
Over a number of years, Entrust has slowly deployed linting. Our first goal was to ensure the linters were not developed by the same team which developed our products. The thought was to minimize the duplication of errors in the policy software and the linting software. We focused on using third party linters for TLS certificates such as cablint and zlint.
Entrust first ran linting against all of our active TLS certificates to find issues and remove errors. We ran post-issuance linting to detect errors, which do not interfere with certificate issuance. When we were happy with the results, we implemented pre-issuance linting.
With pre-issuance linting, if there is a linting error detected a certificate should not be issued. When a pre-certificate is issued for certificate transparency (CT) logging, then the pre-certificate with a linting error will be revoked. The goal of pre-issuance linting is to not miss-issue certificates and provide the details of the error to the team in order to correct the issue.
Although the public certificate linters were designed for TLS certificates, we expanded post-issuance linting to all certificate types. This was done first by only using the non-TLS components of the linters, plus adding other specific components. For each issuing CA, we created a certificate profile, which the CA could issue. This would separate each CA to its certificate type and would narrow down the CA scope to its key usage, extended key usage, permitted key size, hash algorithm, certificate policy, CRL link, etc. We also added in weak key checking, CT logging requirements, and ensured the subject name met the requirements which were validated.
Certificate linting can support the three per cent self-audit requirement from the CA/Browser Forum baseline requirement documents. In fact, since linting is done in an automated fashion, it can be extended to 100 per cent of the certificates. The result is the most extensive and non-subjective self-audit methodology, which may be the primary source of detecting certificate miss-issuance. In the case where a CA miss-issues a certificate which is not detected by linting, the CA may consider updating the linting software to better detect the error in the future. In addition, the linting results and actions can also be provided to the compliance auditor, which shows extensive monitoring and actions when an error is detected.
All CAs issuing publicly trusted certificates should consider certificate linting. Also, CAs which perform linting, but have miss-issued certificates should consider whether linting can be updated to detect the error in the future. Updates to shared linting software will reduce the risk to browser users and the inconvenience to secure server operators.
