Skip to content

Troubleshooting HTTPS failure for custom subdomain on GitHub Pages

Jump to bottom Edit New page
Louis Maddox edited this page Oct 8, 2020 · 7 revisions

HTTPS on GitHub Pages for an apex domain

GitHub Pages allows you to set a custom subdomain by either entering it into the web form or (equivalently) modifying the CNAME record.

For instance, my site at spin.systems is the custom apex domain from github.com/spin-systems/spin-systems.github.io.

The GitHub guide to setting this up formerly advised to use domain forwarding (302 with a mask) but this now appears to have been modified, and now the guidance is only to set up 4 different DNS A records:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

Previously (as I recall) you were only asked to set up 1 A record.

With this, my apex domain spin.systems was able to acquire HTTPS enforcement — GitHub provides this through LetsEncrypt, and it "worked out of the box" for the apex domain.

  • Step 8 of the docs simply says "It can take up to 24 hours before this option is available." i.e. the A records will suffice to acquire the HTTPS option.

HTTPS on GitHub Pages for a custom subdomain

When I then tried to set this up on my subdomain named conf however, I did not get the same result.

From what I can tell from Twitter, in 2016 GitHub did not use CAA, and by 2018 they did (providing the domain registrar supports managing CAA records).

  • My host is GoDaddy, and for all my criticisms of them, DNS is one thing they do allow you to customise through the web interface.
    • Name: *.spin.systems
    • Flags: 0
    • Tag: issuewild
    • Value: letsencrypt.org
    • TTL: Custom
      • Seconds: 600 (this is the minimum permitted, i.e. to refresh this record ASAP)

I probably last tried to set up DNS subdomain records properly in 2016, but didn't manage to get them HTTPS certificated, and probably around 2018 the DNS records I had set up broke entirely (I presume since around this time they switched from suggesting domain forwarding).

Custom subdomains are able to acquire HTTPS certification through CAA records as mentioned above, which I presume will then permit you to use the 'enforce HTTPS' setting in GitHub Pages for the custom subdomain.

Apparently CAA was “a new mechanism” as of 2017 (via)

I am currently waiting for these DNS settings to 'propagate', which I can observe using a DNS lookup utility.

The advice given about wildcard domains appears to implicitly only refer to A records:

Warning: We strongly recommend not using wildcard DNS records, such as *.example.com. A wildcard DNS record will allow anyone to host a GitHub Pages site at one of your subdomains.

This statement only makes sense if interpreted as being about DNS A records. With a DNS CAA record, it means that anyone could... acquire a HTTPS certificate for a subdomain? But then they wouldn't be able to actually set up the redirect for the subdomain without wildcard A records... (I'm pretty certain I have this correct!)

  • Aside: does this mean you could make a 'social network' of GitHub Pages sites using a wildcard A record? :—o Probably of some form...

After waiting for a while and searching the web, I reconsidered what I was doing and why I might not be seeing any DNS propagation (when the other changes propagated quite quickly). I think that in fact, the reason that I don't see the CAA record is because I set it to apply to *.spin.systems, i.e. the wildcard subdomain, yet I checked the DNS records of the apex domain (which would not match the wildcard pattern).

On this hunch (and not seeing it appear for conf.spin.systems either, I came across this Q&A which mentions something important I didn't know:

CAA records are inherited by subdomains - you do not need to publish them under subdomains

Therefore if I place a CAA record on the spin.systems domain (i.e. change the name of the CAA record to just spin.systems without the *. before it) I should expect it to be inherited by all subdomains.

GoDaddy's docs recommend waiting for up to 48 hours for changes to register. (Presumably other DNS records can be added in this time, as long as the CAA is not modified).

Querying DNS records with a DNS lookup utility

The 2 options for DNS lookup on Linux are host and dig. I recommend host for simplicity.

To list all the records for my site I ran:

host -a spin.systems

but oddly, after running this a few times, the output changed and the results omitted the A records for the site. This appeared to be to do with my nameserver, which can be specified simply by adding it after the site whose address is looked up:

host -a spin.systems 8.8.8.8

⇣

Trying "spin.systems"
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45912
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;spin.systems.                  IN      ANY

;; ANSWER SECTION:
spin.systems.           599     IN      A       185.199.108.153
spin.systems.           599     IN      A       185.199.109.153
spin.systems.           599     IN      A       185.199.110.153
spin.systems.           599     IN      A       185.199.111.153
spin.systems.           3599    IN      NS      ns05.domaincontrol.com.
spin.systems.           3599    IN      NS      ns06.domaincontrol.com.
spin.systems.           599     IN      SOA     ns05.domaincontrol.com. dns.jomax.net. 2020100732 28800 7200 604800 600
spin.systems.           3599    IN      MX      10 mailstore1.secureserver.net.
spin.systems.           3599    IN      MX      0 smtp.secureserver.net.

Received 259 bytes from 8.8.8.8#53 in 60 ms
  • This 8.8.8.8 server address is for Google's nameserver, which is often used (but I don't suggest you pass all traffic through there).
  • Note that at the time of writing the CAA record isn't listed, i.e. it hasn't "propagated" out of the domain host [GoDaddy] to the nameserver [in this case Google]

The dig equivalent is more complicated:

dig +nocmd spin.systems any +multiline +noall +answer

To specify the nameserver you prefix it with @:

dig @8.8.8.8 +nocmd spin.systems any +multiline +noall +answer

You can see why I prefer host!

Main page

Add a custom sidebar
Clone this wiki locally