Letsencrypt certificate will not renew

My husband and I created our own Next Cloud server (snap installation) using a Raspberry Pi. We have our own domain, so we obtained a free certificate with letsencrypt. We tried to renew it the day before it expired, but it failed. We’ve since tried to renew it, but it’s a no go. We get the following errors:

pi@raspberrypi:/snap/nextcloud/current/bin $ sudo /snap/bin/nextcloud.enable-https lets-encrypt
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
In order for Let’s Encrypt to verify that you actually own the
domain(s) for which you’re requesting a certificate, there are a
number of requirements of which you need to be aware:

  1. In order to register with the Let’s Encrypt ACME server, you must
    agree to the currently-in-effect Subscriber Agreement located
    here:

    https://letsencrypt.org/repository/
    

    By continuing to use this tool you agree to these terms. Please
    cancel now if otherwise.

  2. You must have the domain name(s) for which you want certificates
    pointing at the external IP address of this machine.

  3. Both ports 80 and 443 on the external IP address of this machine
    must point to this machine (e.g. port forwarding might need to be
    setup on your router).

Have you met these requirements? (y/n) y
Please enter an email address (for urgent notices or key recovery): sandy@xxx.xxx
Please enter your domain name(s) (space-separated): nc.xxx.xxx
Attempting to obtain certificates… done
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
Restarting apache… ERROR: ld.so: object ‘/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
done


Any help would be greatly appreciated!

Hello @Sandy!
I have personally used LetsEncrypt via the CyberPanel, which undertakes its renewal automatically, so I haven’t undergone the process of manually doing it. However, there is an option to force a renewal as shown in the article below:

https://www.cyberciti.biz/faq/how-to-forcefully-renew-lets-encrypt-certificate/

I hope this helps!

Thanks, @vasileios . We’re having a terrible time with it. I may just have to do it all myself from scratch, starting with reinstalling raspberrypi. That’s a project for retirement (only 1 week away!).

2 Likes

You will get there, @Sandy! Sometimes it takes a few efforts, but once done, you’re a pro!

We did it! Got the certificate manually from LetsEncrypt, then ran the enable https command with the “custom” option. When that errored, it told me that I needed to point cert.pem, chain.pem and key.pem, so I did that (pointed them to where LetsEncrypt put them) and “Voila!” it worked!

2 Likes

Congratulations for a job well done, @Sandy! Bravo! :smiley:

My SSL expired and I’m having trouble fixing it. I did the full server setup back in December using CyberPanel and the SSL certificate expired yesterday. I though that I may be notified beforehand but that did not happen. Using the CyberPanel clicked on “issue SSL” for both the domain.com and mail.domain.com, I did it on the hostname and mailserver tabs. Now when I go to my website is shows the SSL is good. But I cannot get any of my email programs to work. When trying to connect it says the SSL is expired. Is this something that will fix itself like the DNS records?

Hey @ksquirrel81!
The Domain Records are independent from the SSL, so there’s no need for you to change them.

First, check to see if the SSL works correctly on the server side. SSH to it, become root, and then execute the following command to see if it’s working properly:

openssl s_client -starttls smtp -showcerts -connect mail.yourdomain.com:25 -servername mail.yourdomain.com

Remember to replace the servername with your actual hostname, and the yourdoman.com with your actual domain.

Please let me know how that goes.

Note: The above command is longer than the display, so make sure you triple-click it to copy the entire thing. :slight_smile:

Hi Vasileios,

I must not understand what a hostname is. I did nslookup with my servers IP address and the output was my domain name, so that is what I used in the command you gave me.

Below is the output I received:

s_client: Option unknown option -mcgrattan.xyz
s_client: Use -help for summary.

I’m guessing this isn’t what I should get?

Hey @ksquirrel81!
You can see your VPS’ hostname by simply tying in the command (while logged into your server):

hostname

Or you can do it via:

cat /etc/hostname

That’s because the name of your server maybe different than the actual domain.

That output is localhost. When I replace servername with localhost it gives me the same unknown option

s_client: Option unknown option -localhost
s_client: Use -help for summary.

What does the following command give you?

certbot certonly --force-renew --cert-name your_domain.ext

Change the “your_domain.ext” with your full domain.

First I had to install certbot, but after I installed it here is what the output was:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?


1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel):

I tried this for both my main domain name, and my mail domain name and both of them gave the same result. I entered ‘c’ to cancel since I didn’t know which one was appropriate.

Since CyberPanel tends to automatically renew the SSL, it just might be a case of having to restart the mail server so that it attains the new data (since CB said everything looked good).
Try the following commands on your VPS terminal (as super-user/root):

postmap -F hash:/etc/postfix/vmail_ssl.map
systemctl restart dovecot.service
systemctl restart postfix

Please let me know if that helps. :slight_smile:

I tried that but it didn’t seem to help. All my email clients still give me the error about the certificate.
when I go to the mail log files on the CyberPanel it looks like it works. It says there is an SSL for the mail server, but the next line is an error. This happens over and over down the log.

[03.31.2022_02-00-03] Checking SSL for mail.mcgrattan.xyz.
[03.31.2022_02-00-03] SSL exists for mail.mcgrattan.xyz. Checking if SSL will expire in 15 days…
[03.31.2022_02-00-03] SSL exists for mail.mcgrattan.xyz and is not ready to renew, skipping…
[04.01.2022_00-00-08] [Errno 2] No such file or directory: ‘/home/cyberpanel/git’. [IncScheduler.git:90]

I have a new problem now. After a lot of trial and error, I did actually get the mail server certificate to work. But when I did that, my main website certificate wasn’t valid anymore. Now when I go to the my main website it says that the certificate is issued to the mail.domain.com website an invalid. So I reissued the SSL to my main website domain.com, and the mail website says its not valid. I went back and forth doing this and I am stuck. It’s like they are completely separate and not connected. I thought the domain.com certificate would pass through to the main.domain.com?

When you go into your website management, does it point that the SSL has a countdown?

Also, there could be an issue with file permissions. Via your website’s management panel, you can enter the file manager and check to see if there is any issues with permissions that disallow any external client to properly read them.

Third option: In Thunderbird, there is a cache Options > Advanced > network and disk space. I have never heard of anything to do with SSL/TLS being cached but it will not hurt to clear it.

The way SSL certificates work can be rather complex, as they can cover the basics or a rather large area. Every relatively cheap SSL certificate out there protects only the top level domain, also known as TLD. This is why a secondary SSL must be issues for the mail subdomain. Unless the SSL is configured to accept wildcards - which is a different process, which will render the certificate able to cover all subdomains (or even sub-subdomains).

So, when you build subdomains, you will need to either make the SSL for that subdomain too, or generate a wildcard certificate outside of CyberPanel. The way to do so is the following: