I think my directories and symlinks are messed up. It is hard when things get duplicated by scripts and you need to clean up after. Sometimes you kill a symlink and create a file where a symlink is expected.
run: certbot certificates
Output:
certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewal configuration file /etc/letsencrypt/renewal/theprequel.org-0001.conf produced an unexpected error: expected /etc/letsencrypt/live/theprequel.org-0001/cert.pem to be a symlink. Skipping.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: theprequel.org
Domains: theprequel.org
Expiry Date: 2018-11-30 15:51:38+00:00 (VALID: 79 days)
Certificate Path: /etc/letsencrypt/live/theprequel.org/fullchain.pem
Private Key Path: /etc/letsencrypt/live/theprequel.org/privkey.pem
The following renewal configuration files were invalid:
/etc/letsencrypt/renewal/theprequel.org-0001.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
So, what lead to this was I did a fully manual install of ghost OR ghost-cli (which is hooey but you can’t tell them that or you hurt their feelings) put certificates in the wrong place. Then, I used certbot to renew and it put them in the right place but named everything as the prequel.org-0001. I wanted to get rid of the old prequel.org files so renamed them all prequel.org-old and renamed prequel.org-0001 as prequel.org. Now, the renewal configuration files are all wrong because they refer to the prequel.org-0001.
There is more strangeness in the directories and symlinks (described below), but ghost and nginx work because they can find certs in a place that the server blocks reference.
So, I have tried to rename things to make the newly setup certs (with expiration Nov. 30, 2018) called just theprequel.org and the former ones (with expiration Sept. 20, 2018) called theprequel.org-old. Ultimately, when this is all setup properly, I can either delete all directories, symlinks, and files using the theprequel.org-old nomenclature–or ignore them because they are not being used at all. Naturally, it’s better to get rid of detritus.
So, I resolved the problem that you see above. I no longer get a message about renewal config. When I run certbot certificates, the output is:
root@lewlin1:/etc/letsencrypt/renewal# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: theprequel.org
Domains: theprequel.org
Expiry Date: 2018-11-30 15:51:38+00:00 (VALID: 79 days)
Certificate Path: /etc/letsencrypt/live/theprequel.org/fullchain.pem
Private Key Path: /etc/letsencrypt/live/theprequel.org/privkey.pem
Certificate Name: theprequel.org-old
Domains: theprequel.org
Expiry Date: 2018-11-30 15:51:38+00:00 (VALID: 79 days)
Certificate Path: /etc/letsencrypt/live/theprequel.org/fullchain.pem
Private Key Path: /etc/letsencrypt/live/theprequel.org/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
But, as you can see certificates with two different names actually point to the same files. That’s where the directories and symlinks seem messed up.
So, here is the current dir structure with symlinks at the file level rather than at the directory level:
/etc/letsencrypt/renewal
theprequel.org.conf # a file
theprequel.org-old.conf # a file
the preceding seems ok. Later, I cat the file so you can we which certificates are setup for renewal.
/etc/letsencrypt/live
theprequel.org
cert.pem -> ../../archive/theprequel.org-0001/cert1.pem
chain.pem -> ../../archive/theprequel.org-0001/chain1.pem
fullchain.pem -> ../../archive/theprequel.org-0001/fullchain1.pem
privkey.pem -> ../../archive/theprequel.org-0001/privkey1.pem
README
theprequel.org-old
cert.pem -> ../../archive/theprequel.org/cert1.pem
chain.pem -> ../../archive/theprequel.org/chain1.pem
fullchain.pem -> ../../archive/theprequel.org/fullchain1.pem
privkey.pem -> ../../archive/theprequel.org/privkey1.pem
README
So, live directory is wrong because I think these are supposed to be symlinks to the archive directory rather than physical directories. Instead, each file in the live directory is symlinked to a file in the archive directory. And both domain name directories contain symlinks to the same files, as certbot certicates reports above.
Here is what the archive directory looks like:
/etc/letsencrypt/archive
theprequel.org
cert1.pem
chain1.pem
fullchain1.pem
privkey1.pem
theprequel.org-0001
cert1.pem
chain1.pem
fullchain1.pem
privkey1.pem
OK, so I didn’t compare all of the files but cert1.pem is the same in both directories, so I think its pretty likely that all the files match. So, it only looks like I have 2 certs. Really, I have the same certs for 2 different domains.
What I am thinking I should do to straighten this out is as follows:
- In directory live, make theprequel.org a symlink to the directory of the same name in archive.
- In directory live, get rid of the directory theprequel.org-old
- even though I thought that theprequel.org-0001 were newer they are the same, but to be on the safe side, in the directory archive rename thepreq.org to the prequel.org-old.
- the in the directory archive I can rename the directory prequel.org-0001 to just theprequel.org
For completeness, this is what the server block in nginx looks like for the domain theprequel.org. This is a symlink from sites-enabled to sites-available and from there symlinked to ghost. That is how ghost does it even though that is not such a hot idea (but the owner is NOT the user that the ghost web server code uses while it is running and serving content). It looks like this:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name theprequel.org;
root /var/www/prequel/ghost/system/nginx-root;
ssl_certificate /etc/letsencrypt/live/theprequel.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/theprequel.org/privkey.pem; # managed by Certbot
include /etc/nginx/snippets/ssl-params.conf;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:2368;
}
location ~ /.well-known {
allow all;
}
client_max_body_size 50m;
}
That looks fine and it won’t see any difference after I clean up the directories.
Do you think my cleanups are the right thing to do?
By the way nginx -t reports that it is happy with the config. Ghost is also happy.