letsencrypt does not replace old certificates?

arjena

Verified User
Joined
May 26, 2013
Messages
54
A couple of months ago I installed a Letsencrypt certificate (via the tutorial on
HTML:
https://raymii.org/s/articles/Lets_Encrypt_Directadmin.html
) on one of the domains on my server. Of course I forgot all about it once it worked. Then I found the certificate expired. So I went through all the steps again, and it worked again. But again the certificte expired.
Since DirectAdmin now supports Letsencrypt, I updated DA, Custombuild and everything else that could do with an update. When I try the SSL install option in the domain, it responds with the expected success message. But when I log in on the site (shop.werpdesign.nl) it still claims the certificate is expired. So it appears it still sees the 'old' certificate. I restarted both DA and httpd, but still I get the 'expired' message on all devices and browsers I tried.
I searched for locations of the cert & key files, but even when I remove them manually (from /usr/local/directadmin/data/users/USERNAME/domains/) the error persists. I would expect some message about no valid certificate present, but I get the message about an expired certificate. So most likely it is still in place somewhere. But where??

So how do I remove all links to older certificates so I can install a new one?

tnx,

Arjen
 
Multiple certificates present?

When I check the domain "werpdesign.nl" on "www.ssllabs.com" it reports several certificates, one of which is valid until march next year, another that appears to be a self signed certificate for the main reseller account (skubbel.nl) and a third, the expired certificate that I want to delete. But where to find it...
 
I'm not sure but did you check /usr/local/directadmin/data/users/username/domains/ if it contains certificates?
 
Richard, thanks for your reply. This morning I decided to reboot the whole server and that seems to have fixed the problem. Apparently there was still something cached or Apache needed a more definite restart, I don't know. But when I run the check now the expired certificate is gone. And I can reach my website again.
Now on to the next problem, getting Prestashop to behave like before I did all the updates. Lots of permission errors now. The fun just never stops...
 
If you decide to install Letsencrypt again, I would suggest to use the Directadmin help pages. :)

With respect to the permission errors, you might try to reset all permissions:
Code:
cd /usr/local/directadmin/scripts
./set_permissions.sh all
 
And what makes you think I did not read the DA help pages? Everything was installed fine, but "service httpd restart" as suggested in DA help did was not enough to erase all traces of the old certificate.
With regards to the permissions problems, these were restricted to Prestashop. Or rather owner problems caused Prestashop to stop working. Ownership of most directories was set to apache, but in order for Prestashop to write to these directories they should be set to user. Or 777 all directories, as actually advised over at the Prestashop forums, but that seems not very safe...
 
And what makes you think I did not read the DA help pages?
The fact that you stated you used https://raymii.org/s/articles/Lets_Encrypt_Directadmin.html to install Letsencrypt. Which looks like a lot more work then I did with the help pages.;) So that gave me the impression.

Ownership of most directories was set to apache, but in order for Prestashop to write to these directories they should be set to user.
Which is exactly what executing the command in my reply should fix.

However, if you have to use 777 to get it to work, you probably are not using php-suexec or mod_ruid2. I would suggest to use mod_ruid2, then you don't need to use 777 on anything including Prestashop. And mod_ruid2 is safer to use then nothing, like it seems the case now.
Only exceptions to this so far I've seen was some badly programmed streaming software.
 
Ah, I see. But I used that tutorial the first time before DA ever mentioned Letsencrypt. I later used it again because I was still on DA1.4 and did not have the time to upgrade. I did that last week, so now I can use the build-in script.
I'm using mod_ruid2. Not sure about php-suexec, it's been a while since I installed the server and (as you can probably tell), this server is more like a hobby than a work thing. However, Prestashop is very picky on privileges. It might install fine (meaning all the privileges are set as Prestashops wants them to be) and some days or weeks later stop working because it cannot write to a certain directory. But ll is fine now, and I learned a lot again :rolleyes:

Cheers,

A
 
Offtopic the rights, if User/Severadmin have PHP FPM then the (DA) fpm User Pool should take care of this so far i know even 755 works then with a lot of cms's ( ofcourse not with user/owner "apache" but then wrong config / and or cms is not doing things right, if you change the owner to the right one this should be working) ( if you make/set the rights changes with FTP then you have to do this with the owner/user ftp account! )
 
Last edited:
But I used that tutorial the first time before DA ever mentioned Letsencrypt.
Ah I understand, it's a lot easyer since it's integrated not so lang ago.

I'm already using mod_ruid2 before it was integrated in Custombuild 2. I also have a Prestashop for a customer online, never had any issues with it. I'm using mod_ruid2 and mod_php.
Normally on owner issues, the "./set_permissions all" or "./set_permissions user_homes" fixes that issue, maybe except for user uploaded files which can be altered another way.

Anyway, glad to hear you have things fixed now.
 
Same here, mod_ruid2 was one of the first things added to my server setup several years ago. I remember because i was very proud of myself pulling that off as a complete unix illiterate. Everything after that is less memorable :).
Anyway, I'll check out those scripts next time an issue pops up. But I hope that will not be any time soon...
Thank for the help,

A

PS @ikkeben: After I changed the owner of all 'shop' directories to user, 755 (for directories and 644 for files) works fine.
 
Back
Top