Hi @codeman1234,
Ugh, that tutorial has a number of problems!
The approach that the tutorial’s author took to renewal is not what we recommend. That crontab entry runs (only) at 1:00 a.m. on the 1st day of even-numbered months and tries to force a renewal at that time regardless of the age of the certificate. (That’s what’s meant by 0 1 1 */2 *, and also by --renew-by-default, which is an obsolete name for the option now called --force-renewal.)
According to this tutorial’s design, your renewal will be attempted only on August 1, because that is the first day of the next even-numbered month. There is actually nothing in the tutorial’s advice that ever checks the age of the certificate.
We don’t prefer this approach because if the renewal fails for some reason, you’ll have very little opportunity to notice and correct the problem. Indeed, there is some indication that it might already have failed since it should also have run on June 1 and performed a renewal at that time (if it was working). If it did run and fail then, which you might be able to confirm from logs in /var/log/letsencrypt, it might also fail again on August 1.
The documented and recommended way to perform renewals is to run certbot-auto renew (e.g. cd /usr/local/letsencrypt && ./certbot-auto renew). This does generally need to run as root. We recommend running this command twice per day. Unlike the certonly --renew-by-default form, it does look at the age of each certificate, and only attempt to renew those that are less than 30 days from expiry.
If you want to renew your certificate right now, you can try the certbot-auto renew form on the command line, and then you can see what’s wrong, if anything.
The renewal configuration file name does not necessarily match the name of a particular domain name if there are multiple domain names that the certificate covers. You can see which ones exist by running ls /etc/letsencrypt/renewal or more detailed summaries of each certificate that you have by running certbot-auto certificates.