Revocation Statuses on the Internet

Abstract

The modern Internet is highly dependent on the trust communicated via X.509 certificates. However, in some cases certificates become untrusted and it is necessary to revoke them. In practice, the problem of secure certificate revocation has not yet been solved, and today no revocation procedure (similar to Certificate Transparency w.r.t. certificate issuance) has been adopted to provide transparent and immutable history of all revocations. Instead, the status of most certificates can only be checked with Online Certificate Status Protocol (OCSP) and/or Certificate Revocation Lists (CRLs). In this paper, we present the first longitudinal characterization of the revocation statuses delivered by CRLs and OCSP servers from the time of certificate expiration to status disappearance. The analysis captures the status history of over 1 million revoked certificates, including 773K certificates mass-revoked by Let’s Encrypt. Our characterization provides a new perspective on the Internet’s revocation rates, quantifies how short-lived the revocation statuses are, highlights differences in revocation practices within and between different CAs, and captures biases and oddities in the handling of revoked certificates. Combined, the findings motivate the development and adoption of a revocation transparency standard.

Appendices

Appendix A. Other CA-Based Behavior Comparisons

We have already seen that different CAs have different revocation-status-handling practices. To provide some additional insights, we obtained day-of-week distributions that capture when CAs change the “Revoked” status to something else (Fig. 9(a)); compare this to the distribution of the first certificate validity day (Fig. 9(b)). Perhaps, the most noticeable are the weaker weekly patterns. While more than half of the CAs issue significantly fewer certificates with start dates during weekends (dark areas for Sat/Sun in Fig. 9(b)), we did not observe such weekly patterns for the revocation status changes. Instead, only a few CAs have spikes of revocation status changes on a certain day (white squares in Fig. 9(a)). For example, Starfield, GoDaddy (part of Starfield), and Digidentify update most of their statuses on Friday, and Japanese Registry on Sunday (Monday Japanese time). The distributions suggest that the relation between last-status-change and certificate-validity-start days is not straightforward. Having said that, some of the CAs have even weekly distributions for both processes, which may suggest higher levels of automation (e.g., Let’s Encrypt, Google, Actalis, cPanel, Gandi, Herndon). Among the large CAs, DigiCert stands out with their pronounced weekly patterns for both processes. Similarly, there are some differences in the daily (Fig. 10(a)) and hourly (Fig. 10(b)) distributions of the expiry times selected for certificates. Here, some of the large CAs (e.g., Let’s Encrypt, GoDaddy, Google, GlobalSign) spread expiry times both across the week and the hours of the days, whereas other large CAs (e.g., DigiCert, Comodo, cPanel, Sectigo) always set certificates to expire at the same time of day. Although these differences may not have major security implications, perhaps, they demonstrate the lack of a standardized policy for managing the revocation status of expired certificates.

Fig. 9.

Weekly distribution of certificate-validity-start day for the revoked certificates and last-status-change day (from “Revoked” to something else).

Fig. 10.

Per-CA breakdown of expiry time of revoked certificates.

Appendix B: Responses by CAs

We contacted 8 organizations that operate the CAs for which we observed at least one status change from “Revoked” to “Good”. However, we did not find a contact email for one CA that no longer operates: AT&T Wi-Fi Services. We received responses from 5 organizations: Starfield (GoDaddy), Japan Registry, Entrust, ACCV, and Atos. The CAs that responded confirmed that they had issued the certificates in question and provided varying explanations for their behavior. Two CAs argued that their use of “Good” statuses was motivated by RFC 6960 [29], which states that “at a minimum, this positive response [i.e., a “Good” response] indicates that no certificate with the requested certificate serial number currently within its validity interval is revoked.” One of these two CAs also stated that they “are going to consult with the community to clarify the requirements, and then, [they will] follow it.” We believe that CAs should avoid changing the status of revoked certificates to “Good” at any time.