
Custom domains on GitHub Pages gain support for HTTPS - mlitwiniuk
https://blog.github.com/2018-05-01-github-pages-custom-domains-https/
======
sinistersnare
I use Cloudflare to get HTTPS on my github pages site, and I really like it. I
get a lot of control over cached content and security, and statistics about
site traffic. I am kind of happy that GitHub did not support HTTPS for custom
domains, because then I would not have learned how to use Cloudflare.

~~~
bad_user
Cloudflare's HTTPS certificate is shared, which means that your website will
share it with other dubious websites.

I'm looking at a website on which I have Cloudflare enabled and my certificate
is being shared with about 24 other domains. For somebody that knows what
HTTPS is about and what it protects against, that's not acceptable. We only
accepted it because we find it as being a reasonable compromise given the
alternative.

So why isn't Cloudflare generating Lets Encrypt certificates, instead of these
shared ones? Given their fast response in pursuing other endeavors, my guess
is that they need incentives for people to move to their business plans.

Therefore I'm glad that GitHub Pages can have HTTPS enabled for custom
domains. It means I can now turn off CloudFlare.

I'm so glad in fact that I started paying GitHub for a $7 account, even though
I don't currently have a need for private repos.

~~~
manigandham
What's unacceptable? There's nothing insecure about sharing a certificate
among multiple hostnames.

Also you can get a dedicated certificate on the free plan for $5/month.

~~~
bad_user
$5/month is $60/year, which is ridiculous.

I maintain 5 websites hosted on 5 different domains (blog in English, blog in
native language and 3 project websites). The cost of 5 certificates would be
$300 per year, or $25 per month.

Right now I'm paying $0 for the certificates of those 5 domains, thanks to
Lets Encrypt.

I've been hosting them myself on a Digital Ocean VPS, with really low
maintenance, since the machine is updating itself and the websites get built
and deployed via Travis. Now I'm moving them to GitHub Pages and my hosting
cost will also be zero.

~~~
manigandham
The certificates are already free, Cloudflare offered them long before
LetsEncrypt. You seem to want a _dedicated_ certificate which is what costs
money, likely because of their scale and existing integrations. There is no
improved security with a dedicated certificate.

You can also host on github pages while using Cloudflare for the custom
domain, which is already the most common setup on github for several years
now.

~~~
bad_user
If there's nothing wrong with those shared certificates, then CloudFlare
wouldn't offer "custom certificates" as a $5/month upgrade.

> _You can also host on github pages while using Cloudflare for the custom
> domain, which is already the most common setup on github for several years
> now._

Yes, because GitHub Pages was not offering HTTPS for custom domains. Now they
do, so that need is gone.

~~~
manigandham
Yes, because people want more, like having multiple levels of subdomains as
the free one only supports a single level.

Security is absolutely not an issue with a shared certificate and Cloudflare
wouldn't get far as a company if they had an insecure product. Why don't you
actually explain what you think is so problematic about sharing a cert?

------
myroon5
HTTPS does work for my site now, but I get this warning:

Your connection is not secure / Your connection is not private

Error code: SSL_ERROR_BAD_CERT_DOMAIN (Firefox)

NET::ERR_CERT_COMMON_NAME_INVALID (Chrome)

Trying adding the A records as described here:

[https://help.github.com/articles/setting-up-an-apex-
domain/](https://help.github.com/articles/setting-up-an-apex-domain/)

Will update if that works..

~~~
city41
I get that warning if I go to
[https://mycustomdomain.com](https://mycustomdomain.com) but I don't if I go
to [https://www.mycustomdomain.com](https://www.mycustomdomain.com)

~~~
fladd
I contacted GitHub support about this already. I hope this gets resolved soon.

~~~
fladd
It turns out that the apex for me now works only by accident, because I
temporarily changed my custom domain to the apex form. This certificate will
not get renewed, however. Only the domain that is active gets a certificate.

That means that with https enabled it is no longer pssible to have the apex
and www form of a custom domain work simultaneously at a GitHub page! One
needs to decide for one or the other.

As a workaround it was suggested to me to create a CNAME record from www to
apex at the domain hoster. This, however, will not work for those of us who
want to have it the other way around, that is, the apex pointing to the www
form of the domain.

I was told that GitHub might consider other solutions in the future.

------
vinhboy
My site says "Unavailable for your site because your domain is not properly
configured to support HTTPS", but I don't see instructions to resolve it?

~~~
Spazer
If your site is configured with A records, you’ll need to change the IPs it’s
pointing to before you’ll be able to get a cert:

185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153

From: [https://help.github.com/articles/setting-up-an-apex-
domain/](https://help.github.com/articles/setting-up-an-apex-domain/)

EDIT: You’ll also need to remove and re-add the domain in the repository
settings after doing that too to trigger it to request a cert.

~~~
myroon5
Can you expand on how to perform the steps added in your edit? Thanks!

~~~
Spazer
Go to the GitHub pages section of the repo settings, delete your domain name
from the custom domain input, hit save, then add it back and save again.

If it’s still not working after that the you can contact support and they can
press a button on the back end to trigger a cert request.

~~~
myroon5
Didn't work for me. Might have something to do with the fact that I also have
a CNAME file in my repo. I'll reach out to support

~~~
mitsudomoe8
Could you please update us once it's done? I have got exactly the same issue.

------
secure
This is great! Now, if only GitHub would be available via IPv6, that would
remove the need for CloudFlare — not that I would necessarily remove
CloudFlare, but I would feel better if my setup wasn’t dependent on it.

------
lostmsu
Hm, I get SSL_ERROR_NO_CYPHER_OVERLAP in Firefox on
[https://stack.blogs.losttech.software/](https://stack.blogs.losttech.software/)
, that is served from [https://github.com/losttech/stack-
blog](https://github.com/losttech/stack-blog) via Cloudflare.

------
Cyberdog
I've been doing HTTPS on hosted domains for years, and I don't really get how
it works in this case. Is it that you don't use your own certificate, but
GitHub automatically generates one with Let's Encrypt for you? If not, then
how exactly do you give GitHub your cert? The instructions seem vague on this.

~~~
sattoshi
You check a checkbox and they generate a cert for your domain. Simple.

------
MightySCollins
Such a shame they quietly broke IPv6 support.

------
jscholes
Could this be related to Google's recent announcement of the .app TLD with
mandatory HTTPS[0]?

[0]: [https://www.blog.google/topics/developers/introducing-app-
mo...](https://www.blog.google/topics/developers/introducing-app-more-secure-
home-apps-web/)

~~~
JepZ
Very unlikely. Github is working on this since months/years [1] and it is much
more likely they had to wait for wildcard support by let's encrypt plus a few
weeks testing.

Googles announcement is much more along the lines of Progressive Web Apps
(PWA) and Service Workers which require HTTPS [2].

[1]:
[https://github.com/isaacs/github/issues/156](https://github.com/isaacs/github/issues/156)

[2]: [https://developers.google.com/web/progressive-web-
apps/check...](https://developers.google.com/web/progressive-web-
apps/checklist)

------
modernerd
Can you host multiple HTTPS sites at different domains from one GitHub
account?

~~~
Spazer
You get a site per repository!

------
pards
Too little, too late.

I moved my repo to GitLab pages after Google announced it would prioritise
sites that support HTTPS in its search results.

~~~
majewsky
You're wildly underestimating how difficult it is to roll out such a change in
a backwards-compatible way. It's not like Github did this today after
neglecting the feature request for years; they've been on public record at
least many months ago saying that they were working on it.

Even if only 1% of users were unable to access a site after the switch to
HTTPS, the amount of calls to Github support would be massive.

~~~
tonyztan
> "It's not like Github did this today after neglecting the feature request
> for years"

[https://github.com/isaacs/github/issues/156](https://github.com/isaacs/github/issues/156)

