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:
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.
You must have the domain name(s) for which you want certificates
pointing at the external IP address of this machine.
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
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:
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!).
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!
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:
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.
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):
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?
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).