I am trying to set custom domain for my Firebase app.
Firebase hosted url : https://inventory-app-726af.firebaseapp.com/
Custom Domain: inv.agsft.com
I have followed all instructions as part of setting custom domain but after verification step when I click on finish button, status will always be "Needs Setup".
I am managing DNS through cloudflare (https://www.cloudflare.com/) and I am following Quick setup option.
Any pointers to resolve it?
I had the same problem, I was able to resolve it by toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records
It started working right away.
The proper solution, ie without disabling Cloudflare for the site, is to use Full SSL for your domain/subdomain.
You can either choose Full SSL for all your domain entries, or set up a Page Rule for a specific subdomain, in your case, use "inv.agsft.com/*"
Source: https://community.cloudflare.com/t/flexible-ssl-redirect-loop-with-google-firebase/2063/3, which in turn points to https://support.cloudflare.com/hc/en-us/articles/115000219871-Why-does-Flexible-SSL-cause-a-redirect-loop-
Had the same issue and this solved the redirect issue. Firebase will however still report the domain as "Needs setup", for that I have no solution, but it does not affect the functionality of the hosting.
For the people that is using Namecheap, This configuration worked for me.
To avoid any kind of ssl issues when using firebase hosting and cloudflare you have to check to following points:
You don't need to toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records unless you don't want the cloudflare ssl certificates and want to just use the firebase ssl certificates (look to this carefully because you will loose the protection that cloudflare provides to your site in case you decide to use only the clouflare DNS)
If you "keep the cloud orange" it will not causes any problem to your firebase hosting.
Add the firebase IP's to cloudflare following the instructions provided by firebase hosting and remove any other A record from your domain/subdomain that you are setting up
To ensure you have a end-to-end encryption (using both firebase ssl as well as cloudflare ssl), make sure that your cloudflare crypto options is set to "Full":
Use a page rule likes in case that you want your root domain to receive all trafic:
In your firebase hosting setup, do the same:
p.s: Look that the message "Needs setup" is still there but the app is running without any problem.
p.s2: the majority problems regarding cloudflare and firebase is that firebase ssl can take several hours to start to work and you keep seeing a message like "your connection is not private". It happens not beucase cloudflare is messing our proxy out but because firebase ssl is still not fully propagated.
I hope it help others :)
In my case I did the same that Brennen did:
toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records.
But just start working when I:
Delete the domain from firebase. (click on the : points select delete domain)
refresh the firebase site
Added again in Quick Setup. I already had the A record added in Cloudflare so I didn't added again.
After that automatically the status added was connected.
Remember: Before testing, clean your browser cache.
When I run dig -t txt +noall +answer inv.agsft.com there are no TXT records showing. Since those are required to verify your ownership of the domain, Firebase Hosting will not continue the setup beyond step one.
Update: since the next step requires you to map A records to the IP addresses of Firebase hosting, I ran the relevant dig too:
$ dig -t a +noall +answer inv.agsft.com
inv.agsft.com. 299 IN A 104.18.56.240
inv.agsft.com. 299 IN A 104.18.57.240
Those are not the addresses I'd expect for Firebase Hosting, so it looks like either you haven't correctly entered the A records, or they have't propagated yet.
When I change my setting like below, it started to work again.
Redirect loop fixed:
For GoDaddy this adding the following solved it for me:
TYPE:A
NAME:#
VALUE: your ip_1
TYPE:A
NAME:#
VALUE: your ip_2
June 2020
Just wanted to share what was successful for me. It was a combination Brennen and Lisbel's answer.
Step 1: Toggle off your DNS status to get a grey cloud (as shown in the earlier answer)
Step 2: Delete the domain from firebase
Step 3: Add it back with Quick Steup
It should be connected after these steps!
I had the same issue. Here's how I fixed it:
1) Cick the View button on the problematic domain (in the Hosting section next to where it says Needs Setup).
2) Change the 'Setup mode' from Quick Setup to Advanced and follow the 3 steps
2a) Open your domain provider's settings (I'm using Google Domains) and add the TXT record it's giving you.
2b) Wait about 4-12 hours for verification
2c) Add the provided A records into your domain provider's settings
This is not a quick process, but it should be working about 5 minutes after you complete step 2c.
Toggling DNS mode didn't work for me. So I tried following approach and it worked for me.
Add CNAME record pointing to {firebase-project}.firebaseapp.com or {firebase-project}.web.app, you could add A record and try.
ADD TXT record as firebase ask you
Verify from firebase (this will show as needs setup, also it didn't go away although this worked)
If new domain/subdomain doesn't works check your browser developer tools network tab. If there are lots of 301 happening then go to cloudflare page rules. Add newdomain.com/* or subdomain.newdomain.com/* then add settings select SSL and set it to full as follows.
Then it will work as expected.
Working as of 11st May 2022 without need to toggle DNS and HTTP Proxy (CDN).
Steps:
Go to Cloudflare Dashboard.
Select SSL/TLS.
Select Overview.
Select Full option for SSL/TLS encryption mode.
After that, refresh your website that previously have issue to access.
Now the website can access successfully.
Related
My domain analogue.design is using Cloudflare's name servers, and caching the A record of analogue.design.
Will that prevent AutoSSL from running in cPanel?
Currently I receive an error in AutoSSL:
DNS DCV: The DNS query to “_cpanel-dcv-test-record.analogue.design”
for the DCV challenge returned no “TXT” record that matches the value
“_cpanel-dcv-test-record=4INs3KmEtlH8IwIA2C3vjAbfrkrmLisoUQomsJJ19oPnm23SdoHHnWeFd5AgbU2M”.;
HTTP DCV: “cPanel (powered by Sectigo)” forbids DCV HTTP redirections.
However, the A records for:
autodiscover.analogue.design
_cpanel-dcv-test-record.analogue.design
are not being cached, they are DNS only.
Help appreciated.
Yes,
If you are using cloudflare as proxy server and if you want to install Autossl Certificate on your server, then you have to pause the cloudflare for your server.
To pause click on overview on the bottom right corner you can see pause cloudflare,
then go to ssl in cpanel, install the certificate using AutoSSL,
it will install the certificate , then again go to cloudflare and run it back
I believe you are adding those records as A record entry and not as txt record with the values provided against them in cloudflare.
Manually check using mxtool or some other online tool available if those needed records are reflecting or not. ( https://mxtoolbox.com/SuperTool.aspx?action=mx%3aanalogue.design&run=toolpage) , it also says not found.
Usually adding those records works for renewing the SSL via autoSSL in cPanel for cloudflare based websites, so probably you are doing something wrong while adding those txt records as explained above.
Quick way would be turn off orange cloud to grey and run the autoSSL, however, you will need to repeat this after every months so not a suggested solution.
On Cloudflare temporarily disable "Always Use HTTPS" in "SSL/TLS" > "Edge Certificates". Then Run AutoSSL. This is happening on cPanel when using Cloudflare, but not DirectAdmin from my experience.
I guess that's a very simple task, but I can't manage to have SSL work on gitlab pages. Gitlab pages documentation is too vague for me.
For example, when they say "Make sure your domain doesn't have an AAAA DNS record." does that mean the subdomain (say gitlab.mysite.com) doesn't have a AAAA record. Or does it mean my whole DNS configuration shouldn't have such a record?
Also if that's the later, how can I manage to make this work?
Maybe someone has a source to a good tutorial for this because I really struggle finding simple information (not assuming any prior knowledge about SSL/gitlab).
I just went through the whole process beginning to end and set up a GitLab Pages website on a custom domain with a Let's Encrypt certificate -- it worked like a charm.
I had to:
a) set up a TXT record to verify domain ownership, and
b) add an A record to point at the GitLab Pages IP address (since my domain DNS management provider didn't allow me to set up a domain-level CNAME)
After this, GitLab went and fetched a Let's Encrypt certificate for my Pages web site.
I didn't have a AAAA record, so that didn't come into the picture.
As per GitLab Pages documentation section GitLab Pages integration with Let's Encrypt,
Caution: This feature covers only certificates for custom domains
Issue 3342 is open to add support for sub-domains.
If you are still having trouble, let me know, I'd be happy to help with this.
I'm trying to set up https on my backend app on heroku as a subdomain like this (for example):
https://api.mydomain.com
and I'm really confused by all the conflicting online docs I've found. Also, I'm rather green on all this SSL stuff. This app will be a backend for just data serving. My front end right now is https on OpenShift under my domain and it's working fine. Here is what I've done:
I have a "hobby" dyno ($7/month) on my heroku app, which I read that I need to
enable this stuff.
I have a cloudflare account which serves up my domain for the openshift front-end on https.
I bought my domain from GoDaddy -- so right now it simply points to the cloudflare name servers.
I setup the subdomain: api.mydomain.com on heroku (settings tab). It came back and said that my "DNS Target" is api.mydomain.com.herokudns.com. It also says "Domain: Your app can be found at http://api.mydomain.com".
I clicked "Configure SSL" > "Automatically configure using Automated Certificate Management" and it comes back saying to:
"update your DNS settings to our secure domain"
Not really sure what that means, to be honest. I tried to go back to cloudflare and add a DNS Record (DNS tab). Like so:
Type: CNAME
Name: api <--is this right?
Value: api.mydomain.com.herokudns.com <-- what do I put here?
But this doesn't work. How do I know? I type
heroku certs:auto and it comes back 'failing'. Also tried value: mydomain.com.herokudns.com without the 'api' in front. I'm really confused and the docs aren't much help. Can anybody help me?
I have found a simpler solution. The fix was mentionned in Cloudflare's tutorial.
The trick is to take your standard heroku app address (ex: myapp.herokuapp.com) INSTEAD of the xxx.herokudns.com displayed in heroku's SSL interface
Then, to make your custom subdomain (ex: api.foodomain.com) point to it, simply add a CNAME record in Cloudflare's DNS
CNAME api myapp.herokuapp.com
And it should work (it did for my case).
OK, in case some other poor tired programmer comes here.
Cloudflare and Heroku don't get along. Use your SSL from cloudflare. Here's how:
disable automatic certification on heroku: heroku
certs:auto:disable
Delete your domain on heroku and start over
Add the (sub) domain again on heroku
type heroku domains to see what the REAL domain is now -- without ACM enabled it will probably go back to ...herokuapp.com instead of ...herokudns.com
Set that one up in cloudflare (DNS tab) under CNAME like so:
CNAME | yoursubdomainname | yourdomainname.com.herokuapp.com
set up Page Rules in cloudflare to be like so:
http://yourdomainname.com/ => Always use https
on Crypto tab use Full SSL.
Wait an hour or so to make sure these all take effect.
Hope that helps someone.
<--------- Update ---------->
So I tried using digicert instead of SSL Labs and this is what I got. This is why my ssl isn't working properly with CloudFlare and Heroku.
<--------------------------->
For some reason, my CloudFlare SSL isn't working properly and I continuously get this error. Really lost and could use some help. Below are screenshots of the error and my CloudFlare Crypto Settings.
I have fixed the issue here. Turns out it was a simple fix. All you have to do on CloudFlare is make sure the subdomains e.g. www are routed through cloudflare as well instead of through the primary host e.g. heroku.
You can do this by clicking on the cloud next do you CNAME record and making sure it's orange.
I also recommend using www.digicert.com instead of www.ssllabs.com because you get a lot more helpful information.
Cheers,
Have you tried using an SSL testing tool like https://www.digicert.com/help/ or https://www.ssllabs.com/ssltest/index.html ? They might help narrow down where the problem may be.
Good luck!
I have set up a domain name to use Cloudflare. I have tested SSL and all seems well. However I have found that it can cause webfonts to not display in IE11. So I tried to "bypass" cloudflare by clicking on the orange cloud for the status of the A and CName record withing Cloudflare\DNS. The orange cloud icon goes grey.
So I have switched from:
Orange Cloud: Records that display an orange cloud icon are accelerated and protected by CloudFlare
To:
Grey Cloud: Records that display a grey cloud icon will bypass CloudFlare, using only CloudFlare DNS
However when I then try to load up www.mydomain.com again in IE I still get "https://", as prefix, which implies that the domain is still not bypassing Cloudflare. I tried again after 10 mins, cleared temporary files and I still get no resolution.
I have now worked out that restarting the IE browser solves this, but I am not sure why. Is this to do with the 301 page redirect that my page rule invokes to "Always use https" for pattern "/*". Is there a way to clear this without closing and restarting the browser?
Linked to the above I found that I could only get "Full" SSL to work to force "HTTPS". "Flexible" SSL still allowed "HTTP" for some reason.
Advice on the above appreciated.
DNS records do have a Time To Live before the they update (I believe this is 299 seconds on domains set-up using CloudFlare full-host DNS), however I do not think this issue is a CloudFlare problem.
A https prefix does not mean a site is using CloudFlare as there could be an SSL on the origin server. Using the command line I would advise you ping the domain to find if it's routing through CloudFlare or not. You can do this by typing:
ping yourdomain.com
If it routes to your IP Address you know it's not on CloudFlare, if it points to an IP on the CloudFlare network then you are routing through CloudFlare (in which case wait for it to propagate, clear your cache, if you still have no luck raise a support ticket with CloudFlare).