这是一篇迁移自 Ballot SC-086v3: Formalizing the Sunset of IP Reverse Address Domain Names in TLS Certificates 的文章。
The CA/Browser Forum has formally adopted Ballot SC-086v3, a significant update to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates. This ballot addresses the long-standing, though increasingly anomalous, practice of including IP reverse address domain names—specifically those under the in-addr.arpa and ip6.arpa domains—in publicly trusted TLS certificates. With unanimous support from both Certificate Issuers and Certificate Consumers, the motion marks a definitive step toward aligning certificate practices with the intended architecture of the Internet’s Domain Name System (DNS).
Background and Rationale
IP reverse address domains serve a technical role in DNS: they facilitate the mapping of IP addresses back to domain names through reverse DNS lookups. The in-addr.arpa domain is used for IPv4 addresses, while ip6.arpa serves IPv6. These domains are infrastructure components, not application-layer identifiers meant for human interaction or web services. Consequently, including them as subject identifiers in TLS certificates has long been viewed as inconsistent with both security best practices and the semantic purpose of certificate validation.
Despite historical allowances, no legitimate use case has emerged that justifies the inclusion of such names in publicly trusted certificates. Their presence introduces unnecessary complexity, potential for misuse, and ambiguity in certificate validation logic. Ballot SC-086v3 responds to this by instituting a clear sunset provision, effectively prohibiting future issuance of certificates containing these names.
Ballot Process and Voting Outcome
Proposed by Corey Bonnell of DigiCert and endorsed by representatives from Apple and Opera, the motion underwent the standard CA/Browser Forum governance procedure. A seven-day discussion period commenced on October 23, 2025, followed by a formal voting window that concluded on November 10, 2025.
The ballot received overwhelming support:
- Certificate Issuers: All 26 voting members voted YES, including major CAs such as DigiCert, GlobalSign, GoDaddy, and Let’s Encrypt ‘s parent organization (via NAVER Cloud Trust Services).
- Certificate Consumers: All three voting browser/root program representatives—Apple, Google, and Mozilla—also cast YES votes.
This unanimity underscores a shared consensus across the ecosystem that the practice has outlived any residual utility.
Compliance with Forum Bylaws
The adoption met all procedural requirements under the CA/Browser Forum Bylaws:
- More than two-thirds of Certificate Issuer votes favored the ballot (26/26).
- More than 50% + 1 of Certificate Consumer votes were in favor (3/3).
- At least one member from each category voted affirmatively.
- Quorum was satisfied, with 29 total votes exceeding the required threshold of 16 active voting members.
These validations ensure the ballot’s legitimacy and enforceability under the Forum’s governance framework.
Technical Implementation
The substantive change is codified as a modification to Version 2.1.7 of the TLS Baseline Requirements. The exact diff is captured in the GitHub comparison between commits b6a014d and b249b19 in the cabforum/servercert repository. While the rendered comparison was too large for GitHub to display inline, the change effectively amends Section 7.1.4.2.1 (or its equivalent) to exclude in-addr.arpa and ip6.arpa from the set of permissible domain names in TLS certificates.
CAs will be required to comply with this update once it is formally integrated into the published Baseline Requirements. Given the nature of the change—a prohibition on a rarely used feature—the operational impact is expected to be minimal.
Review Period and Intellectual Property Considerations
Following adoption, the ballot entered a 30-day Review Period under the CA/Browser Forum’s Intellectual Property Rights Policy, beginning on November 14, 2025, and ending on December 14, 2025. During this window, Forum members may submit Exclusion Notices if they believe the guideline implicates essential claims under their patents. The availability of redlined and clean versions of the guideline—in both Word and PDF formats—facilitates thorough legal and technical review.
Conclusion
Ballot SC-086v3 represents a refinement of the Web PKI ecosystem’s boundaries, eliminating a vestigial practice that diverged from the DNS architecture’s design principles. By formally sunsetting the inclusion of reverse IP address domains in TLS certificates, the CA/Browser Forum reinforces the principle that certificate identifiers should reflect meaningful, user-facing hostnames—not internal infrastructure artifacts. This change enhances clarity, reduces attack surface, and aligns certificate policy with decades of Internet engineering consensus.