bppwrite / bppwrite.github.io

https://newplays.org
0 stars 0 forks source link

GitHub Pages Offers Free HTTPS for Custom Domains Now #39

Open mattbatman opened 6 years ago

mattbatman commented 6 years ago

We should take advantage of this.

marcguyer commented 6 years ago

I saw that the other day... Very cool. I'm sure we'll be using it for various things Cheddar. Do you want to set it up for newplays.org?

mattbatman commented 6 years ago

I could, but I'd need access to the account with which the domain was purchased. It's just a matter of switching the IP addresses that the A records point to as outlined here. I think we also need to remove and add the CNAME here again.

marcguyer commented 6 years ago

There's a gotcha here. If you go to https://newplays.org, it works fine. If you go directly to https://www.newplays.org, you'll see a security warning. I'm guessing because only the apex domain and not the www subdomain is set as a SNI for the cert. The fix could be to redirect www to apex (or the opposite if BPP wants to use the www subdomain. Often, DNS providers can manage this but I'm not sure about Dreamhost. Or, maybe config change in GH pages.

mattbatman commented 6 years ago

Via quick googling, I didn't see a mindless set of directions spelling out exactly what to do. I believe they were already configured to redirect from www to apex before I switched the A records to the new IP addresses.

screen shot 2018-05-10 at 10 18 08 pm
marcguyer commented 6 years ago

A CNAME is not a redirect. I think we need to do a standard http redirect and remove that CNAME. It's typically trivial to config a redirect via DNS service. It's not part of DNS, really, but an additional service of DNS providers. We do it with Dyn for the Chdr blog subdomain...

mattbatman commented 6 years ago

My impression thus far is that DreamHost's redirect configuration between a subdomain and apex only works when you're using them to fully host the site. They have a little radio button selection between www/non-www preferences, but i's in their "Fully Hosted" section.

They have a separate redirect section, but it doesn't seem to allow setting up a rule to redirect from a subdomain even though it says that "sub-domains are okay!"

marcguyer commented 6 years ago

I appears on the surface that Dreamhost doesn't do a good job of redirecting www to the apex. When you enable a redirect (e.g. www.newplays.org -> newplays.org), DH automatically sets the A record to point to the Dreamhost IP while Github Pages needs the A record(s) to be pointed to Github's IP(s). I wonder if Dreamhost's support people would be of any help here. Here's what happens to DNS settings when you set the redirect:

screen shot 2018-05-29 at 9 04 18 am

... and further down the page ...

screen shot 2018-05-29 at 9 05 00 am

As you can see, the "custom" A records are still there pointing to Github but there are 2 more - a 5th A record for the apex and another for the www subdomain point to 75.119.200.205 (Dreamhost's IP).

The solution, it seems to me, would be for Dreamhost to only set the A record to Dreamhost's IP for the www subdomain so that www (hosted at DH) can redirect to the apex (hosted on Github Pages). I wonder if Dreamhost's support people would be of any help in making that happen...

marcguyer commented 6 years ago

I went ahead and started a ticket with DH support.

marcguyer commented 6 years ago

Ok, I've enabled the redirect in DH after receiving an indication from DH support that the redirect shouldn't interfere with the custom apex A records set for Github Pages. If you go to http://www.newplays.org, you should be redirected to https://newplays.org

marcguyer commented 6 years ago

I had to beg DH support to remove that 5th A-record manually. That took care of that problem but the redirect doesn't work anyway because we want SSL. Before DH does the redirect, they'd have to negotiate SSL just to product the redirect for the client. That's not going to happen.

A CNAME is not a redirect. I think we need to do a standard http redirect and remove that CNAME.

I think I jumped the gun here, as I'm prone to do. To get both www and the apex domain working (with www redirecting to the apex), we need Github Pages to do it. So, I think the CNAME is probably the way to go (assuming it's possible at all). Due to the lack of commentary on the tubes on this topic, it's likely easier than I thought. I just removed the DH redirect and added the CNAME www->apex. After DNS propagates, we'll test.

marcguyer commented 6 years ago

I asked Github Support and here's what they had to say:

Thanks for reaching out about this! We don't currently support creating a certificate that covers both your root domain and your www subdomain. We only generate a certificate for the exact domain that you specify in the custom domain input box. I will add your +1 to that feature request internally though!

In the meantime you can work around this by pointing your www subdomain CNAME at username.github.io, and entering the non-www version of your domain into the input in the repository settings.

Keep in mind that this redirect will only work when using a protocol-less or http:// link. If you explicitly specify https://www.example.com you will still likely encounter a certificate error.

I've configured the CNAME, so, everything is working except a direct request to https://www.newplays.org. In that case, you'll get the security warning but it'll still work if you bypass the warning. If this isn't agreeable, we can remove SSL altogether. I'm sure Github will start setting alternative names for certificates soon. I wouldn't be surprised if they've heard this complaint enough to get a fix in place quickly.