GitHub Pages CAA Records: A Hidden Hurdle for Custom Domain SSL & Developer Productivity
Unpacking a Critical GitHub Pages Bug Affecting Custom Domain SSL
A recent discussion on the GitHub Community forum has brought to light a significant issue impacting users of GitHub Pages with custom domains: restrictive CAA (Certificate Authority Authorization) records. This bug, detailed in a developer report by user xiaohuilam, highlights how default configurations are inadvertently limiting developers' choices for web security and hindering overall developer productivity.
The CAA Record Conundrum
The core of the problem lies with the automatically configured CAA records on xxx.github.io subdomains. These records explicitly restrict which Certificate Authorities (CAs) are permitted to issue SSL certificates for the domain. Currently, GitHub Pages subdomains are configured to allow only Let's Encrypt, Sectigo, and DigiCert.
The issue arises when developers configure their custom domains (e.g., abc.com) to point to a github.io subdomain via a CNAME record. Due to DNS inheritance rules, the custom domain automatically inherits these restrictive CAA records. This prevents users from obtaining SSL certificates from any CA other than the three pre-approved ones, even if they prefer or require a different provider like Certum.
Xiaohuilam provided a clear illustration of these inherited records using the dig command:
➜ ~ dig test.github.io. caa
; > DiG 9.10.6 > test.github.io. caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32168
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;test.github.io. IN CAA
;; ANSWER SECTION:
test.github.io. 3600 IN CAA 0 issue "letsencrypt.org"
test.github.io. 3600 IN CAA 0 issue "sectigo.com"
test.github.io. 3600 IN CAA 0 issuewild "digicert.com"
test.github.io. 3600 IN CAA 0 issuewild "letsencrypt.org"
test.github.io. 3600 IN CAA 0 issuewild "sectigo.com"
test.github.io. 3600 IN CAA 0 issue "digicert.com"
;; Query time: 2703 msec
;; WHEN: Sat Feb 14 03:00:16 CST 2026
;; MSG SIZE rcvd: 234Impact on Developers and Proposed Solution
For developers relying on GitHub Pages for hosting, this restriction creates unnecessary friction. It undermines their ability to choose their preferred SSL certificate provider, which is crucial for website security, compliance, and user trust. The original poster emphasizes that when users point their own domains to GitHub Pages, restricting their SSL certificate options is certainly not their intention.
The proposed solution is straightforward: GitHub should remove these default CAA records for xxx.github.io subdomains. This change would empower users to freely apply for SSL certificates from any CA for their custom domains without being constrained by inherited records.
GitHub's Response and What's Next
The feedback was promptly acknowledged by the GitHub Actions bot, indicating that the developer report has been submitted to the product teams for review. While there's no immediate solution or workaround provided, the discussion serves as a vital piece of community feedback. This type of detailed developer reports are essential for GitHub to understand and address pain points, ultimately enhancing the platform and supporting better developer productivity for its vast user base. Developers are encouraged to upvote and comment on the discussion to show support and add further insights.