The cert preexisting hadn’t dawned upon me! Interesting! Now that I’m getting through the bumps I can see that might yet another issue. Thanks for digging into this.
The Let’s Encrypt service limits requests for the same certificate to 5 time a week. If you’ve reached this limit, you can’t get another certificate (unless you request the same certificate alongside a new subdomain, for example.)
Some time ago, I decided not to use Let’s Encrypt, and handle SSL with a free Cloudflare account. To achieve this, you’ll need to use Cloudflare nameservers, and then generate SSL certificates in their dash for authenticated pulls. Cloudflare will then sort the public certificates, and renew them automatically.
All I had to do was upload the certificates to /etc/ssl, and skip SSL and Nginx setup when installing Ghost. If you need some guidance setting up Cloudflare, just reach out.
Hey Martin,
Sorry this step has taken me a few days. I finally had the time to sit down and work on this. I’ve made an account at cloudflare, and repointed the DNS servers. I’m at the waiting interval. I’ll work on this tomorrow, but should I start over from the beginning again. Or just restart ghost setup?
Hey Martin,
Thanks for the continuing assistance. I’ve created/copied the new certs on the server and I’m about to edit the .conf file. Do I just erase everything in there and copy your’s over? This is new territory for me. I continue to research this on the side.
Fritz
current config:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
I have default, fourankles.com-ssl.conf and fourankles.com.conf. These are artifacts of the ghost setup I believe.
Fritz
ps. I just took a look in both of the confs and they are blank.
pss. I’m guessing you want me to overwrite the default. That seems like it matches your example config.
Here’s the output:
nginx: [alert] could not open error log file: open() “/var/log/nginx/error.log” failed (13: Permission denied)
2023/06/26 18:55:44 [warn] 1368#1368: the “user” directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2023/06/26 18:55:44 [emerg] 1368#1368: open() “/etc/nginx/sites-enabled/fourankles.com-ssl.conf” failed (2: No such file or directory) in /etc/nginx/nginx.conf:60
nginx: configuration file /etc/nginx/nginx.conf test failed
PS I was thinking that when we sort out the issue with nginx that we’d need to figure out how to get away from letsencrypt. Or did we do that by altering the nginx config?
Hmm, that didn’t seem to work to well. Here’s the output:
nginx: [emerg] open() “/etc/nginx/sites-enabled/fourankles.com-ssl.conf” failed (2: No such file or directory) in /etc/nginx/nginx.conf:60
nginx: configuration file /etc/nginx/nginx.conf test failed
No, this has worked. That’s the reason Nginx won’t start.
You still have a symbolic link in /etc/nginx/sites-enabled for the original Nginx config file, but the file no longer exists. You can delete: sudo rm /etc/nginx/sites-enabled/fourankles.com-ssl.conf, and then rerun sudo nginx -t.