Koozali.org: home of the SME Server
Contribs.org Forums => Koozali SME Server 10.x Contribs => Topic started by: Randall on July 16, 2022, 08:40:08 AM
-
I'm having a problem renewing my Lets Encrypt certificate. It appears to be unable to authenticate, getting a 403 response. Checking the file access rights of the Primary ibay as outlined in the Lets Encrypt (0.5.22) contribs page reveals all to be exactly as documented, yet attempt to access http://my.server/.well-known/acme-challenge/#### returns 403 Forbidden.
This This may be due to other issues, as I noting that the original default "Under Construction" web page at http://my.server/ also gets a 403. Other ibays serving web content seem OK. File rights noted:
[root@e-smith ibays]# ls -l
total 0
drwxr-xr-x. 5 root root 46 Mar 6 2009 Primary
drwxr-xr-x 6 root root 67 Mar 6 2009 public_files
[root@e-smith ibays]#
Only thing I can see is that Primary has SELinix attrubutes (note dot after access flags):
[root@e-smith ibays]# ls -Z
drwxr-xr-x. root root system_u:object_r:user_home_t:s0 Primary
drwxr-xr-x root root ? public_files
Unfortunately, deleting the attributes didn't help. Anybody got any idea what to look at, or why that folder has SELinux attributes ?
Thanks in advance.
-
selinux should be disabled with SME Server.
check you did not enabled it.
also check your httpd error log
-
Thanks for the quick reply.
The log is telling me that there does appear to be an access rights issue:
[Sat Jul 16 09:20:53.145764 2022] [core:error] [pid 27220] (13)Permission denied: [client 104.248.172.107:32776] AH00132: file permissions deny server access: /home/e-smith/files/ibays/Primary/html/index.htm
According to sestatus, SELinux is in fact disabled, so not sure how those attributes got set. A mystery for later, I guess.
However, it appears that the Letsencrypt documentation (https://wiki.koozali.org/Letsencrypt) may be incorrect (or something else has changed). According to that, the ibays/Primary should look like this:
drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin
drwxr-s--- 2 admin shared 4096 Jul 25 2016 files
drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html
which is how mine looks:
drwxr-s--- 2 admin shared 6 Mar 6 2009 cgi-bin
drwxr-s--- 2 admin shared 6 Mar 6 2009 files
drwxr-s--- 3 admin shared 58 Jul 15 23:56 html
I changed the rights of the html directory to 777, and was able to renew my certificate, but access to default web pages still fails. At least the panic is off for now.
Continuing to experiment a bit further, changing the Primary/html/ rights back to 2750, and changing it's ownership to apache:shared, and also changing ownership of Primary/html/index.htm to apache, I am now able to access the default page. However I'm no longer able to access via SMB.
Something appears messed up. I'm guessing this is supposed to be accessed as admin, but is actually being accessed by user apache. Perhaps apache was previously running as admin and changed to apache in some update ?
Any thoughts ?
-
we do not use apache but www. apache is an alias to user www to allow compatibility with some upstream packages like mailman.
www is supposed to be member of group shared.
most probably your issue is lying there.
grep shared /etc/group
-
Bingo !
Thanks a lot.
-
Or maybe apache followed by www order in /etc/passwd that's causing the error?
-
On my server www was missing from shared group. I actually don't see apache in that group at all either (not sure if this is another potential issue or not). I'm also not sure how this got excluded in the first place). Also, I'm pretty sure the the group is a simple set, with only membership and no concept of order.
-
any contrib?
first install or restore?
for how long the letsencrypt contrib has been installed ?
when did occurrs the last certificate update successfully ?
what has been installed or done since?
this should do the trick:
usermod -a -G shared www
-
Thanks. Seems to be happy now (access default web via web, though only r/o via SMB).
I have a few contribs installed, ddclient, NextCloud, Letsencrypt, dhcpdns. Letsencrypt was installed May last year, and has been working fine. Received expiry notification for exipry Apr 25, (all kept working so it updated), then a couple for expiry July 15 (rcvd Jun 28, Jul 5). Have only been applying updates (probably not as frequently as I should), no new contribs. That's about it.
-
first good news
second to avoid it to happen again to you or maybe other :
any changes since apr 25?
updates?
new contribs?
-
I don't think I've made any changes beyond applying updates. I did notice one time that when I applied updates it said that I needed to reconfigure before I started, though I'm pretty diligent about doing that after updating, so I don't know what happened there. Maybe sitting in that state broke something. I did reconfigure before applying new updates, though.
-
I did reconfigure before applying new updates, though.
do you mean you have
signal-event post-upgrade; signal-event reboot
or just
signal-event post-upgrade
if only the latter then you put your system in an unstable state waiting for reboot to finish configuration.
it is better doing nothing than half bake the cake.
Currently only kernel, openssl, glibc and few similar libraries require a signal-event post-upgrade; signal-event reboot
-
When I do it manually via command line I do both. More frequently, I apply updates via the UI, and hit the Reconfigure button at the bottom after it's complete, which triggers the reboot.
-
nice.
will need to find why this happened. and probably add a routine to make sure www is member of shared.
-
nice.
will need to find why this happened. and probably add a routine to make sure www is member of shared.
Hi,
I had a similar issue while trying to update my certificate:
[root@mail ~]# dehydrated -c -x
# INFO: Using main config file /etc/dehydrated/config
Processing mail.xxx.com
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 19 11:32:06 2022 GMT (Less than 30 days). Renewing!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for mail.xxx.com
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for mail.xxx.com authorization...
+ Challenge is valid!
+ Cleaning challenge tokens...
+ Requesting certificate...
+ ERROR: An error occurred while sending post-request to https://acme-staging-v02.api.letsencrypt.org/acme/finalize/41303368/3513424704 (Status 500)
Details:
HTTP/1.1 100 Continue
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Fri, 05 Aug 2022 13:06:30 GMT
Content-Type: application/problem+json
Content-Length: 112
Connection: keep-alive
Boulder-Requester: 41303368
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 0002_Rm4guoJk_6rQSJn5MjnDCuttAqc9KoL2ffFHT8DwxI
{
"type": "urn:ietf:params:acme:error:serverInternal",
"detail": "Error finalizing order",
"status": 500
}
/usr/bin/dehydrated: line 737: 1: unbound variable
EXPECTED value GOT EOF
If then applied "usermod -a -G shared www" .... Ran it again and it went though ok.
-
This has happened again. Identical symptoms. www was no longer a member of shared group. I noticed that the group file was last touched on the same date I last applied updates.
Confirmed that this gets removed when applying updates:
- Re-inserted the www into shared group (usermod -a -G shared www), rebooted
- Verified that root web page is now accessible
- Applied latest updates via UI
- Noted www was still present in shared group
- Issued signal-event post-upgrade; signal-event reboot via shell (UI had closed, was inaccessible)
- When dust had settled, it was broken again.
Presumably my cert should update now ...
-
please show output of
cat /etc/passwd | egrep "www|apache"
Edited to add 'code' tags
-
Here ya go:
[root@e-smith ~]# cat /etc/passwd | egrep "www|apache"
apache:x:102:102:Apache:/var/www:/sbin/nologin
www:x:102:102:SME Server web server:/home/e-smith:/bin/false
[root@e-smith ~]#
-
I am wondering if you happen to change the default Primary Ibay group from shared to something else ?
-
No, I haven't changed anything like that. Just added new groups. Though it's probably got 15 years or so of update history from earlier versions, so maybe something from it's past has finally caught up ...