SSL setup is not working about ghost-cli

[acburdine]

@frunk48 yes this is the case - letsencrypt has to verify that you actually own your domain - and to do so it sends an HTTP request to your domain's configured IP address. It can't send the request over https because the cert hasn't been configured yet.

[MrAdam]

This was completely my mistake. I tried running the following directly in the console:

/usr/bin/nodejs /usr/local/lib/node_modules/ghost-cli/node_modules/.bin/greenlock certonly --agree-tos --email ****@gmail.com --webroot --webroot-path /var/www/ghost/root --config-dir /etc/letsencrypt --domains ******.dk --server https://acme-v01.api.letsencrypt.org/directory'

It gave me an error related to a base64 encoding/decoding module.
I googled it, and found out that I was using an old version of Node which handled things differently.

My suggestion:
Do a Node version check in Ghost-CLI when people try to install, and notify about it being an unsupported version on node :-)

[acburdine]

@MrAdam thanks for finding out what the issue was! I'll bump the minimum supported Node version to v4.5 in the next release - that should fix the base64 issue.

The actual notice about it is here: https://git.daplie.com/Daplie/node-greenlock#install -> I just missed that when developing the letsencrypt setup.

[baldlion]

I am getting the same error MrAdam was seeing. I tried removing the /etc/letsencrypt folder and re-running ghost setup ssl but the error persists. I am using Ghost 1.0.

? Enter your email (used for Let's Encrypt notifications) <email>
✖ Setting up SSL
A ProcessError occured.

Error occurred running command: '/bin/sh -c /home/<user>/.acme.sh/acme.sh --issue --domain <domain> --webroot /var/www/<ghost install folder>/system/nginx-root --accountemail <email>'

Exit code: 1


Debug Information:
    Node Version: v6.11.1
    Ghost-CLI Version: 1.0.0
    Environment: production
    Command: 'ghost setup ssl'

Additional log info available in: /home/<user>/.ghost/logs/ghost-cli-debug-2017-07-28T00_38_25_295Z.log

Here are the contents of the referenced log file:

Debug Information:
    Node Version: v6.11.1
    Ghost-CLI Version: 1.0.0
    Environment: production
    Command: 'ghost setup ssl'
Error occurred running command: '/bin/sh -c /home/<user>/.acme.sh/acme.sh --issue --domain <domain> --webroot /var/www/<ghost install folder>/system/nginx-root --accountemail <email>'

Exit code: 1

--------------- stdout ---------------
[Fri Jul 28 00:38:20 UTC 2017] Single domain='<domain>'
[Fri Jul 28 00:38:20 UTC 2017] Getting domain auth token for each domain
[Fri Jul 28 00:38:20 UTC 2017] Getting webroot for domain='<domain>'
[Fri Jul 28 00:38:20 UTC 2017] Getting new-authz for domain='<domain>'
[Fri Jul 28 00:38:21 UTC 2017] The new-authz request is ok.
[Fri Jul 28 00:38:21 UTC 2017] Verifying:<domain>


--------------- stderr ---------------
[Fri Jul 28 00:38:24 UTC 2017] <domain>:Verify error:Invalid response from http://<domain>/.well-known/acme-challenge/xOPOkhxK1AKTfuboX6N2zpNlKz4gRcManQdJ7TqGs1M:
[Fri Jul 28 00:38:24 UTC 2017] Please add '--debug' or '--log' to check more details.
[Fri Jul 28 00:38:24 UTC 2017] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh

[acburdine]

@MrAdam yeah, others have reported this occurring before, am not 100% sure why 😕

One user reporting being able to fix the issue by removing the /etc/letsencrypt directory and trying again. Would you be willing to try that and report back? (Make sure you don't have any other letsencrypt certificates on that server first 😛)

Quick command to do that: sudo rm -rf /etc/letsencrypt && ghost service nginx-ssl <youremail>)

[ErisDS]

I keep getting a similar error:

A ProcessError occured.

Error occurred running command: '/bin/sh -c /usr/bin/nodejs /usr/lib/node_modules/ghost-cli/node_modules/.bin/greenlock certonly --agree-tos --email <email> --webroot --webroot-path /var/www/test-ghost-2/root --config-dir /etc/letsencrypt --domains <domain> --server https://acme-v01.api.letsencrypt.org/directory'

Exit code: 1

Debug Information:
    Node Version: v6.10.2
    Ghost-CLI Version: 1.0.0-alpha.16
    Environment: production
    Command: 'ghost service nginx-ssl <email>'

It's possibly a totally different cause, but the lack of output is preventing me from debugging. I think it might be a permissions problem, or a problem with the domain not being reachable, can't quite tell!

[acburdine]

@ErisDS if you get a ProcessError, it should output the stdout and stderr of the command into a ghost-cli-debug.log file inside your ghost folder. I'll open an issue to add a line to the debug output saying something like: "More debug info found here: ".

[kirrg001]

Note: Somehow ghost service nginx-ssl EMAIL doesn't work anymore.

[acburdine]

Gonna close this as ssl generation should be fixed for the most part by #238 - if there are further errors we can reopen this (again 😛). Not sure what the original cause was, but the command no longer requires sudo, so it should be a little more sane to run.

[morajabi]

I have problem with Setting up SSL.

[ErisDS]

@morajabi the onus is on you here to provide some information if you want someone to help you.

[acburdine]

@baldlion are you sure your domain is pointing at your server's IP correctly? That is what would cause the error you are seeing - acme is failing to validate your domain which means something is not pointing correctly.

[baldlion]

@acburdine Yes - I can access ghost from my domain. I have a Type A DNS Record with my domain as the hostname and a value that matches the droplet's IP address (using Digital Ocean). Could it be in my nginx config?

[morajabi]

@acburdine Yes I guss my issue was this. I got exactly the same error. Can’t we show an appropriate error though?

[baldlion]

I did a fresh install and no longer got the error

[morajabi]

@baldlion How? I have the problem.

[shinyamagami]

@morajabi I had the same error as baldlion's, and it got fixed after pointing my domain at my server.

[frunk48]

I faced the same problem, but in my case it turned out to be because my security group on my EC2 instance where I was trying to deploy was not allowing requests over port 80 (HTTP). It appears that the tool requires that both 80 and 443 be open.