Does GitHub Pages Support HTTPS for www and @ subdomains?

I got one of the new .app TLDs that went live today, and I am trying to point it to Github pages. I want the default URL to be without the www (host: @) and for the www to redirect to the default. I have set the domain without www in my pages repo settings, enabled https, and done the A and CNAME records in my DNS.

The A record is working fine, it loads my site with no www. The CNAME for www is causing an issue with the SSL certificate though. If I open the site in Edge, postman, curl, etc, it works fine; however, .app requires HTTPS and Chrome knows that, so it doesn’t even bother trying http and goes straight to the HTTPS version when you type www. This gets an error because Github returns the certificate, and not my own.

Is there a fix for this?


Hi @tsmith18256,

Thanks for being part of the GitHub Community Forum!

GitHub doesn’t currently support creating a certificate that covers both your root domain and your wwwsubdomain. We only generate a certificate for the exact domain that you specify in the custom domain input box. That said,  we’re always working to improve GitHub, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.



This answers my question – I have two github projects with pages that are now HTTPS-enabled, but only for <name>.com.  Attempting “https://www.<name>.com/” makes Chrome complain loudly.  I’m hesitant to check the “force HTTPS” box because there’s a lot of references to www.<name>.com.

The documentation on seems to suggest that simply adding a CNAME will work – the last step in the CNAME setup process is adding/removing to trigger HTTPS.  The docs should probably be updated to reflect the current state of things.


Hi @fadden,

Thanks for this feedback! We’re always working to improve GitHub, and we consider every suggestion we receive. Though I can’t share a timeline for this, I can tell you that your feedback has been shared with the appropriate team.


I’m having the same issue. Any word on a solution?


Hi @isaacdozier,

This is currently not possible still. This may be released as a feature in the future, but I can’t make any promises currently. Please keep an eye on the GitHub Changelog for information when this is released.


1 Like

Until this gets implemented, you can use Cloudflare to serve certificates for your other subdomains, which I write about here: In the example I used, you would have a CNAME for the www subdomain that points to the FQDN (, or with DNS/HTTP Proxy enabled. For the rest of the A records, set it to DNS only. Finally, create two Cloudflare page rules: always use HTTPS and 301 redirect from no-www to www. The example also assumes that you use “” as your Github custom domain. Once you set these settings up, you may need to remove and re-add your custom domain so that Github can see the new DNS settings. If you did everything correctly, verify via curl that you see a Github-issued certificate for “” and a Cloudflare-issued certificate for “


I’m like 90% of the way there. I have and https://example and all redirecting and loading properly with CloudFlare + GitHub Pages. But I cannot get to redirect, I still get an SSL_ERROR_BAD_CERT_DOMAIN. My setup is: CNAME (flattened) CNAME GitHub Pages Enforce HTTPS is off Clearly is redirecting to which then redirects to https; but a direct https connection to www does not work. Has anyone gotten this to work? I might just ditch GitHub pages and host some other way instead, but I really wanted to teardown my (pointless) VM.


Support for both an apex and subdomain cert would be appreciated.

e.g. if I had the following in the CNAME file I’d expect them to both be covered:

Only allowing one to be covered by the cert isn’t apparent when you set a site up.


1 Like

May I suggest modifying the feature request about supporting subdomains, to automatically creating wildcard certificates for custom domains, so ANY subdomain is supported (not just www):




Is there any news on this topic? Or at least a confirmation that one day github will protect “” and “” via ssl?

1 Like

Hi @adrai,

At this point, there is no news on this front. Keep an eye on the GitHub Changelog to be notified of new features.


I’m also a little disapointed this is not supported properly. 


I think I’ve managed to make this work by accident.

We had: in the github pages settings.

@ on domain pointing to github web servers

www CNAME @

Status was

http:\ - works

https:\ - works, cert good

http:\ - works

https:\ - cert error

For an experiment, I went into the github pages settings and set the config to be

My experiment didn’t work, so I flipped it back.

But now https:\ works, and https:\ does too.  SSLLabs is happy with both certificates (which are from Let’s Encrypt).

It may be that flipping the setting to www caused a new certificate to be generated.  Time will tell whether this cert gets renewed at its 3 month expiry time, or whether github forgets about it.  Anyway, it seems to work for now.


I will be a +1 on that request.

Just bought a .dev domain and was planning on keep it on github as a cv page, but since it needs an SSL cert (.dev rules) now I can’t access it from the www subdomain. Not that I actively use it or share the url with it, but it’s good to have the option. Right now the visitor will receive a cert error.

I understand not generating * certs to avoid abuse, but a www is pretty default and should be generated together with the apex domain when the repository is configured to a apex, since it’s the same thing.


Any update on this? Having users meet Chrome’s “Your connection is not private” screen when they incude/exclude the www subdomain is a bit of a massive problem.


I’d also like to know if there’s any work being done to solve this. 


I don’t think that this will work, as GitHub uses LetsEncrypt. LEs wildcard certificates need the Acme v2 endpoint and this requires regular DNS (TXT) changes for renewing the wildcard certificate.

please allow both “” and “

The work-around is to set first “” and then after the certificate is issued, change it to “” in this way they will both work.

But they will not be both renewed.

Just fix this!

1 Like

I agree… wilcard certificate would be very nice… so I can set a domain * which will all go to the same github page.

but still… even only and would be a nice option.