It produced this output: Command failed: /bin/sh -c sudo -S -p '#node-sudo-passwd#' /etc/letsencrypt/acme.sh --issue --home /etc/letsencrypt --domain blog.flytag.com --webroot /var/www/ghost/system/nginx-root --reloadcmd "nginx -s reload" --accountemail guttikonda@live.com
[Sat Sep 26 02:26:17 UTC 2020] blog.flytag.com:Verify error:DNS problem: NXDOMAIN looking up A for blog.flytag.com - check that a DNS record exists for this domain
[Sat Sep 26 02:26:17 UTC 2020] Please add '--debug' or '--log' to check more details.
[Sat Sep 26 02:26:17 UTC 2020] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
My web server is (include version): Debug Information:
OS: Ubuntu, v18.04.5 LTS
Node Version: v12.18.4
Ghost Version: 3.34.1
Ghost-CLI Version: 1.14.1
The operating system my web server runs on is (include version): OS: Ubuntu, v18.04.5 LTS
My hosting provider, if applicable, is: Google Cloud VM
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
With this method, the certificate authority is trying to connect to each name listed in the requested certificate. As you can see, you requested blog.flytag.com to be one of those names, so the certificate authority would like to connect to it to verify that you own it.
But right now in DNS, blog.flytag.com has an A record pointed at 0.0.0.0, which is an invalid address that nobody can connect to. This is different from the record for flytag.com, which has two A records, for 151.101.65.195 and 151.101.1.195. If blog.flytag.com is going to be hosted on the same server, you should update its A record so it will be possible to connect to it at the same address as flytag.com.
If it's not going to be hosted on the same server, the current method that you're using to obtain a certificate will not be able to obtain a certificate that covers blog.flytag.com. In that case you should either use a different method, or leave blog.flytag.com out of this certificate entirely and request a separate certificate for it from the server where it is actually going to be hosted.
My sceanrio is flytag.com will be pointed to https://flytag.firebaseapp.com - A record IPs 151.101.65.195 and 151.101.1.195 blog.flytag.com will be pointed to self hosted ghost blog in google cloud platform vm - A record IP is 35.184.93.103
I'm trying to run the SSL from 35.184.93.103. Please let me know if doing something wrong?
① you should point the DNS name to the Google Cloud Platform VM before requesting a certificate for it (Let's Encrypt expects it to be "up and running" already using the kind of method that you're using)
② you should request separate certificates for flytag.com and blog.flytag.com using software running directly on their respective servers
If the server where you were running the software (with the commands you showed above) is the GCP service at 35.184.93.103, then try changing the DNS A record for blog.flytag.com to point there first, and then request the certificate only for that name, not for the base domain name. In this case, you should also see if Firebase support or the Firebase community (I don't know anything about this platform) can advise you about how to get a certificate up and running there—it might require a totally separate process managed by Firebase.
Let's Encrypt certificates can be obtained by lots of different software (there are several dozen applications to request them in different software environments), but a common pattern is that the certificate should usually be requested on the same server where it will ultimately be used, by running software on that server, as its administrator or with the help of its administrator, with the DNS records already in place first. (While there are alternatives to this, they're usually quite a bit more complicated and may require a deeper understanding of Let's Encrypt and your individual environment.)
Thanks again for clearly point out what needs to done. Now, I have to rerun the "ghost setup ssl" from 35.184.93.103 only for blog.flytag.com. Have a good one!! Thanks Again!
This is my DNS setting. I have the DNS A set for blog.flytag.com 35.184.93.103 and running certbot command from that server 35.184.93.103 resulted in below error
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for blog.flytag.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. blog.flytag.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://blog.flytag.com/.well-known/acme-challenge/idEQ_oTlDaT_7shiLz8qTRzv2yQpbuqoRDjaLXHYJaY [151.101.1.195]: "\n<!doctype html>\n\n \n Site Not Found\n <link href='https://fonts.googleapis.com/css?family=Robot"
Site Not Found\n <link
href='https://fonts.googleapis.com/css?family=Robot"
<p>To fix these errors, please make sure that your domain name was<br>
entered correctly and the DNS A/AAAA record(s) for that domain<br>
contain(s) the right IP address.</p>
</li>
</ul>
<p>Started understanding but really confused now.</p>
Yes...That's why I'm confused. That's the A record for the primary domain flytag.com. Please refer the screenshot attached. I'm trying to setup ssl for sub domain blog.flytag.com
Curiously, both blog.flytag.com and 35.184.93.103 are both serving the correct certificate. I'm also getting the right IP address (35.184.93.103) with several different tools. Cached IP lookup perhaps? Slow propagation?
To host a static site in Cloud Storage, you need to create a Cloud Storage bucket, upload the content, and test your new site. You can serve your data directly from storage.googleapis.com, or you can verify that you own your domain and use your domain name.
I did not work on the issues last night. Just deleted it.
Also I ran the sudo certbot and got this message. But I'm unable to conclude what fixed the issue, Propgation issue or extra entry of the same server ip to blog.flytag.com.flytag.com.
