Undo `ghost setup nginx ssl`

Developer help Installation
1

The Ghost initial setup has been great. I am running a v5.40.2 on a Ubuntu 22.04 server.

Background

However, I then tried to add an A record for an external IP address in my DNS settings, pointing it to a subdomain (example.mydomain.com). The SSL validation then failed in the browser, though I do not know the cause.

Problem

I attempted to add the subdomain in a similar fashion shown here but later realized I do not want to do this:

ghost config url https://example.mydomain.com   // not a www.* subdomain
ghost setup nginx ssl
ghost config url https://mydomain.com

See the steps copied from this article for reference: Ghost-CLI - A fully loaded tool for installation and configuration

I have not run this command yet to set the new [undesired] configuration.

sudo nginx -s reload

Ask

Is there anything I can do to undo this new configuration? I do not know if it would it be safe to simply remove the nginx configuration like this or if there are additional considerations to be made (e.g. for the ssl portion of ghost setup ...)?

sudo rm http://etc/nginx/sites-enabled/example.mydomain.com.conf

Thanks in advance for your help!

2

I assume you want to change from a bare domain to a subdomain? If so, change the URL in Ghost, create a new Nginx config in sites-enabled, create a symbolic link to sites-enabled.

You’ll need to unlink the bare domain in sites-enabled, and generate new SSL certificates.

Finally test the Nginx config, and then reload the server.

3

Thank you, that’s not quite what I was asking though there was some useful information in there!

I’m trying to add an A list record for another subdomain other than Ghost. Ghost is configured on my root domain but I would like to add another service at example.mydomain.com which points to an IPv4 address.

However, when I do this simply through my DNS provider it appears there is no SSL certificate configured, with the browser showing:

Your connection is not private
Attackers might be trying to steal your information from example.mydomain.com (for example, passwords, messages, or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID

The tutorials I see from the service seem to indicate it should work as expected but I’ve noticed non-supported subdomains (i.e. abc.mydomain.com) do not show [as expected] but use a plain http:// connection. It seems like there should be a way to support https:// on the entire domain, rather an explicitly defined subdomains…? (in the manner shown in the explicitly defined subdomains section here)

I was wondering if I you might know what to do with the nginx and/or ssl configurations to make this work?

4

I’m still uncertain what you are trying to achieve. From what I gather, you have a Ghost site working okay on the bare domain, and want to set up another using a subdomain. Is this correct? Additionally, do you intend using Ghost with the subdomain?

5

:white_check_mark: Correct, I have a self-hosted ghost site working on the bare domain.

On the subdomain, I’m trying to point to a non-Ghost server IPv4 address. The A list record on my DNS provider is set, but the SSL certificate is failing. Does that make sense?

6

The basic requirements are to request certificates, and then to include these in your Nginx config. For example,

sudo certbot certonly -a webroot --webroot-path=/var/www/abc.mydomain.com/html -d abc.mydomain.com

and then add the following lines to Nginx.

ssl_certificate /etc/letsencrypt/live/abc.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/abc.mydomain.com/privkey.pem;
1 Like
7

Got it! And just to confirm, letsencrypt is certbot (or is this some different package)?

8

Sorry, use certbot not letsencypt. Certbot is the client tool; I’ve amended my post.

1 Like
9

I think I found the problem: Let’s Encrypt will only certify content derived from the host. I think I will need to find another certificate authority to provide one that can verify content from an external IP address.

For additional context, here’s the command I gave to try and the response it gave:

$ sudo certbot certonly --webroot -d example.mydomain.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for example.mydomain.com
Input the webroot for example.mydomain: (Enter 'c' to cancel): var/www/example.mydomain.com/html

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: example.mydomain.com
  Type:   unauthorized
  Detail: XX.XX.XXX.XX: Invalid response from http://example.mydomain.com/.well-known/acme-challenge/rz-DO0t34GNh8lHc3ynpn5n_BFQnfC15SE1DcL7TWjo: 404

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
11

You haven’t stated what the other “server” is, but if you’re proxying the service from the same server as you’re running Ghost, then the A record should point to this server, and the certificate can be issued.

Otherwise, request the certificate from the origin server.

1 Like
12

Okay, I requested the certificates from the origin server with:

openssl s_client -showcerts -connect XX.XX.XXX.XX:443

I learned that while there were valid certificates, there were none yet issued for this particular subdomain. I’ve reached out to request a fix; you so very much for your help diagnosing this!

1 Like