-
Notifications
You must be signed in to change notification settings - Fork 129
GitHub Pages: Generate SSL certificate for www subdomain when a custom domain is set to an apex (and vice versa) #1675
Comments
meanwhile, for a subdomain, e.g.
When pointing this to githubuser.github.io/repo_name, it doesn't seem that the issued SSL cert works for me. |
@gotexis Is your CNAME set to |
Hey thanks for your response. I found out the problem in my case, turn out the cert was not issued yet as it is stated in the settings, so when I visit the site I got the default gitHub cert which is not valid for my custom domain. I think although this was resolved by simply waiting a bit longer, it is still a bug |
Same here:
|
Same here: https://www.kycp.org = OK, https://kycp.org = KO |
I don't know if its the same issue or not but my certificate expires every 3 months and then it takes 2 months for automatic renewal. This really sucks. |
Many sites are currently broken (if you come in on the secure www site) because of this. On a github community page a user has pasted a list of "popular websites currently broken websites to demonstrate how pervasive this issue is in practice".
|
Site is working, except for `https://www.joshjavier.com` which returns an SSL certificate error (code `SSL_ERROR_BAD_CERT_DOMAIN`). There is an [open issue](isaacs/github#1675) related to this. Based on docs, www subdomains are more stable and load faster due to better implementation of DoS attack protection. If this causes issues, revert to using apex domain.
Personal preference. Also, many of my blog inspirations who use their name as their personal domain are doing it. To name a few: - https://github.com/tomcritchlow/tomcritchlow.github.io - https://github.com/jingruzhang/jingruzhang.github.io - https://github.com/swanson/swanson.github.com For SEO, it doesn't matter which I choose, as long as I stick to it. No more switching. Note: isaacs/github#1675 is still unresolved, so `https://www.joshjavier.com/` will not work, but it's a trade-off I'm willing to make.
I think, I finally understood the recommendation of github to redirect example.com to www.example.com through DNS server. Through this, you will always land on github through your www. domain and the single SSL certificate for the custom www-domain is sufficient. |
Update CNAME to point to `www.` subdomain as a workaround for Github pages [SSL error](isaacs/github#1675). This is a temporary fix.
Since I was building my site with GA actions, I ended up deploying my |
Agreed on the importance of this request! ☝️ Regarding solutions given this limitation...
To the extent that it's helpful to others, the configuration using Google Domains DNS is via a synthetic record: It's perhaps not the ideal solution, but with this configuration anyone navigating to the |
I got this from the GitHub support team today:
|
From their documentation: «If you are using an apex domain as your custom domain, we recommend also setting up a www subdomain. If you configure the correct records for each domain type through your DNS provider, GitHub Pages will automatically create redirects between the domains. For example, if you configure www.example.com as your custom domain for your site, and you have ALIAS and CNAME records set up for the apex and www domains, then example.com will redirect to www.example.com. For more information, see "Managing a custom domain for your GitHub Pages site."» They recommend doing things like this but it only works without HTTPS. :( |
https://gist.github.com/amingilani/332f3b5102f65a63719b2b4578b50108 The easiest way is to do it through Cloudflare |
I ended up going with an alternative solution to danilo, which some might consider simpler. What we know is:
To solve this issue, what I did was enable http proxy on cloudflare for www.example.com only. And enable https on cloudflare. If I got to www.example.com it will serve the github response (that would otherwise have an invalid cert) that redirects to example.com, which was already working as expected. It is a bit odd to have www.example.com and example.com using different certificates from different certificate authorities, but it isn't a problem. |
From GitHub Pages can now automatically secure the www variant of your custom domain:
Has anyone had a chance to test it out on an existing site? |
@lubo yes, it works. I configured |
Did you literally configured it around the time you wrote your comment? Because I still see a warning page in Firefox but that may be because DNS changes have not been propagated yet. In any case, glad they fixed it. Although I already hosted my site elsewhere, it if turns out this works I may switch. |
I actually changed it yesterday |
Hmm.. Than it should have been updated. I mean, I know it said that DNS changes take 24h to propagate but in practice it happens often faster. As I never visited your website before I doubt it is a cache thing. And I'm curtain as I just installed a now OS yesterday. |
I went to my Pages settings (the new page described in the blog post) and saw a series of dialogues telling me a new certificate was being generated: After a little while it was done, and then waiting ten more minutes or so, it now looks like it works! I can go e.g. to my website using www: https://www.scifiagenda.com/ which redirects to the apex version. Inspecting the certificate I can confirm both www and apex are included in the cert: It seems like going to the same settings page for my other website triggers that same process. |
hmmm, I see the issue in google chrome, changed the |
Per the documentation, and what worked for me, is using |
yep, but it didn't work when I changed it yesterday. I think the script didn't work yesterday or was overloaded, but when I changed the dns settings today, GitHub was able to see the changes and generated the certificates. But now I see this warning: will changed the DNS back to |
I've just tried it myself and it works. After changing the DNS record for my apex domain, all I had to do was to access Pages settings, where the change in DNS was detected and the message captured by @alimony was displayed. However, the message was not being displayed after refreshing the settings page. Nevertheless, it took just under 10 minutes since seeing that message. I think this can be closed as fixed. |
yep, can be closed |
Hey @SVilgelm, I can see your website now. Well done! |
Can confirm it works, you just have to be a bit patient after making the changes.
All in all, it took about 30 min. |
Don't hesitate to ping us (the Pages team) at https://github.community/c/github-help/github-pages if you run into issues setting up |
Right now https://obtuse.dev works fine however https://www.obtuse.dev gets a SSL Error. I am hoping this will generate a certificate for www subdomian that will fix the issue. ref: isaacs/github#1675
There's a loooooong discussion over at https://github.community/t5/GitHub-Pages/Does-GitHub-Pages-Support-HTTPS-for-www-and-subdomains/td-p/7116 about this — incorrectly marked as "solved," of course.
When setting a custom domain on a GitHub Pages repo to a root domain, like
example.com
, a Let's Encrypt certificate for it is generated when Enforce HTTPS is enabled (obviously). But there is absolutely no way to havewww.example.com
redirect to the root/apex domainexample.com
with a valid SSL certificate as well.It absolutely sucks having to add yet another service into the mix just to get https://www.example.com to redirect to https://example.com without showing a certificate warning. It seems like a pretty safe assumption that if someone enters an apex domain then they'll want www to mirror it/redirect to it — wanting different content at @ and www is a super rare edge case (and probably accidental if it does occur, to be honest).
Certain domain registrars and/or DNS providers can do this for free (Google Domains, Cloudflare, etc.) but I'd love to keep things consistent re: hosting...and, of course, my personal DNS provider and many others charge extra for this.
Please add
www
as an alt name on the LE certificate by default if the user inputs an apex domain as the custom domain!The text was updated successfully, but these errors were encountered: