Closed Korsani closed 1 month ago
Huh why did you add your domain in the shellscript?
Huh why did you add your domain in the shellscript?
Running freely, the script attempt to renew bunch of certificates (by fetching the domains in mysql db), among them, for example, louisegoutheraud.fr
. When renewing this domain, the script makes a directory called autodiscover.louisegoutheraud.fr
. That is fine : on next round the directory is still there.
That is NOT the case with bl-evolution.com
, as I described : it creates the directory autoconfig.bl-evolution.com
(whereas every other domains end by creating autodiscover
). To try to track down what happen, I add the domain in the script so that running with bash -x
only show what happen with that (guilty) domains, and not with the good ones.
My guess is that the line 337 DOMAINS=${VALIDATED_DOMAINS_SORTED[@]} /srv/obtain-certificate.sh rsa
make a wrong directory (autoconfig
instead of autodiscover
), because ${VALIDATED_DOMAINS_SORTED[@]}
contains wrong informations because line 322 VALIDATED_DOMAINS_SORTED=(${VALIDATED_DOMAINS_ARR[0]} $(echo ${VALIDATED_DOMAINS_ARR[@]:1} | xargs -n1 | sort -u | xargs))
contains mails.<domain> autoconfig.<domain> autodiscover.<domain>
for bl-evolution.com
and autoconfig.<domain> autodiscover.<domain>
for others. Why /srv/obtain-certificate.sh
then create autoconfig
and not autodiscover
? idk.
So, next round assume that the directory autoconfig
is in orphaned directory (why ? i didn't investigate, it was really late :) ) so it deletes it.
Workaround it to symlink autoconfig.bl-evolution.com
to autodiscover.bl-evolution.com
. So that the reverse-proxy nginx finds its autodiscover.bl-evolution.com
Mmm... I realize that maybe my case is badly named. The nginx reverse-proxy expects certificates in autodiscover
. Which, as I mentioned, do not happen with bl-evolution.com
: certificate is created in autoconfig
.
Still, there is a mismatch between what nginx conf expect, and what /srv/acme.sh
does. I'll investigate on our side to see where the nginx conf comes from.
I dont really know if this related but when i add a fdqn in the acme-mailcow config as an aditional san (as follows):
ADDITIONAL_SAN=smtp.*,myfdqn.de*
And restarting acme-mailcow manually it gets the certificate but after a while (about 1 day) it is gone again.
Acme also dosent generate a new one (yes i did run docker compose up -d
)
and after looking at https://crt.sh/ i can confirm that no new ssl cert has been issued
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
I dont really know if this related but when i add a fdqn in the acme-mailcow config as an aditional san (as follows):
ADDITIONAL_SAN=smtp.*,myfdqn.de*
And restarting acme-mailcow manually it gets the certificate but after a while (about 1 day) it is gone again.Acme also dosent generate a new one (yes i did run
docker compose up -d
) and after looking at https://crt.sh/ i can confirm that no new ssl cert has been issued
So turns out taht it was a " " ive misplaced that caused my issues somehow 🤷
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Contribution guidelines
I've found a bug and checked that ...
Description
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
x86
Operating System:
Debian Bookworm
Server/VM specifications:
32G ram, Intel(R) Xeon(R) CPU D-1520 @ 2.20GHz
Is Apparmor, SELinux or similar active?
don't know
Virtualization technology:
don't know
Docker version:
24.0.6
docker-compose version or docker compose version:
v2.21.0
mailcow version:
2024-02
Reverse proxy:
nginx
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check: