Issue #7003: firewalld.org has broken HTTPS due to redirect - fedora-infrastructure

fedora-infrastructure

#7003 firewalld.org has broken HTTPS due to redirect

Closed: Fixed May 31, 2018 Opened May 30, 2018 by erig0.

I need someone to create an ALIAS record for firewalld.org to firewalld.github.io to fix SSL for https://firewalld.org. If ALIAS is not possible, then A records should be used (contents would be same as firewalld.github.io)

As per: https://help.github.com/articles/setting-up-an-apex-domain/#configuring-an-alias-or-aname-record-with-your-dns-provider

Below follows my original report via email.
--->8---

I'm the current project maintainer for firewalld and also maintain the content at firewalld.org.

At the moment https://firewalld.org results in a SSL error.

firewalld.org uses an invalid security certificate.
The certificate is only valid for the following names:
  *.redhat.com, redhat.com
  Error code: SSL_ERROR_BAD_CERT_DOMAIN

I think this came about because the website use to be hosted on
fedoraproject.org, but at some point was moved to github pages. When
that happened a redirect was setup. The current DNS record points to
redirect.redhat.com.

$ dig firewalld.org
firewalld.org.      82255   IN  A   209.132.183.105
$ dig -x 209.132.183.105
105.183.132.209.in-addr.arpa. 284 IN    PTR redirect.redhat.com.

This is all good for HTTP, but does not work for HTTPS as shown above.

Github suggests using an ALIAS or ANAME record for using github pages with custom domains [0]. This seems pretty straight forward and is just a matter of updating the DNS. This should alias firewalld.org to firewalld.github.io.

[0] https://help.github.com/articles/setting-up-an-apex-domain/#configuring-an-alias-or-aname-record-with-your-dns-provider

I hope that explains the issue well enough.

puiterwijk commented May 30, 2018

So, my email reply was:

 Unfortunately, ANAME/ALIAS records are not an actual official DNS record type.
They are basically "advertising" names for certain authorative DNS
server implementations that do CNAME flattening at the domain apex on
the DNS server side.
This is not something our setup supports unfortunately, since bind
does not have an implementation of this, and the fact that we actually
keep our DNSSEC keys offline.
So I'm afraid the best we could offer here is to manually do the CNAME
flattening now, and just have you ping us everytime GitHub Pages
decides to change their IP, but I'm not sure that that's something we
really want to (since during that time, it might be offline).

Unfortunately, I just checked, but it looks like Github pages is now fronted by fastly, which is a CDN, which often change actual IP addresses quite often.
So as said, while we could do manual flattening, this means a big risk that the domain apex will be unavailable for long periods if they changed the IPs.
That was the reason we often go for redirect.redhat.com: that IP address is static, and we'll be able to get a headsup way in advance if it ever changes.

erig0 commented May 31, 2018

@puiterwijk, I think if you use an A record requests will bypass the CDN and go to github directly [0]. While this is not ideal, it may be our best option.

[0] https://blog.github.com/2014-01-07-faster-more-awesome-github-pages/

Edited May 31, 2018 by erig0

puiterwijk commented May 31, 2018

DNS zonefie is updated: https://infrastructure.fedoraproject.org/cgit/dns.git/commit/?id=2de1a55.
It will take 15 minutes to synchronize out, and then 24 hours for local DNS caches to flush.

Metadata Update from @puiterwijk:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

May 31, 2018

erig0 commented May 31, 2018

Thanks @puiterwijk, I'll close this ticket once I can see the DNS changes on my end!

Metadata Update from @erig0:
- Issue status updated to: Open (was: Closed)

May 31, 2018

Metadata Update from @erig0:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

May 31, 2018

puiterwijk commented May 31, 2018

@erig0 sidenote: note that the certificate for https://www.firewalld.org/ has expired.

erig0 commented May 31, 2018

@puiterwijk, please check again. It has since been regenerated. It should all be good now. Looks fine on my end.

puiterwijk commented May 31, 2018

@erig0 unfortunately, I'm still being served the outdated certificate:
openssl s_client -showcerts -servername www.firewalld.org -connect www.firewalld.org:443
shows as cert:

x509 info:

        Validity
            Not Before: Feb 28 17:50:28 2018 GMT
            Not After : May 29 17:50:28 2018 GMT

erig0 commented May 31, 2018

Hrm..

https://firewalld.org works as expected
https://www.firewalld.org shows the expired cert

erig0 commented May 31, 2018

@puiterwijk, the current www CNAME points to firewalld.github.io. Should it point to firewalld.org instead?

;; ANSWER SECTION:
www.firewalld.org. 77305 IN CNAME firewalld.github.io.
firewalld.github.io. 3265 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 916 IN A 185.199.108.153
sni.github.map.fastly.net. 916 IN A 185.199.109.153
sni.github.map.fastly.net. 916 IN A 185.199.110.153
sni.github.map.fastly.net. 916 IN A 185.199.111.153

erig0 commented May 31, 2018

I filed a github ticket and their reply was essentially:

we only support certs on a single domain as specified by the repository settings.

As such, https://www.firewalld.org will not work and there is currently no way to fix it. We must use https://firewalld.org. All variants of the HTTP URLS will be upgraded to HTTPS - so http://www.firewalld.org does work.

Metadata

Assignee

None

Tags

None

Blocking

None

Depending on

None

Priority

Lowest

fedora-infrastructure

#7003 firewalld.org has broken HTTPS due to redirect Closed: Fixed May 31, 2018 Opened May 30, 2018 by erig0.

Metadata

#7003 firewalld.org has broken HTTPS due to redirect

Closed: Fixed May 31, 2018 Opened May 30, 2018 by erig0.