Also ich habe bei uns mal auf ein paar Servern geschaut und da stehen immer beide Cronjobs:
15 1 * * * /opt/pdadmin/bin/letsencrypt --all
05 3 * * 2 /opt/pdadmin/bin/letsencrypt --renew
Hat meiner Meinung nach aber auch keiner bei uns manuell eingetragen.
Ist bei mir auch auf allen Servern, nur auf einem nicht, da sind aber komischerweise bisher auch immer Renews gelaufen. Erst seit einem länger überfälligen SE-Upgrade wohl nicht mehr. Habe es mal ergänzt. Doof nur das damit in den letzten Tagen schon jede Menge Zertifikate abgelaufen waren und es heute einem Kunden aufgefallen war 
Das ist meist so. Das ist Murphys Gesetz.
würde pd-admin nicht die Fehlermeldungen unterdrücken, wäre folgendes aufgefallen …
# INFO: Using main config file /opt/pdadmin/etc/dehydrated.conf
ERROR: Problem connecting to server (get for https://acme-v02.api.letsencrypt.org/directory; curl returned with 27)
EXPECTED value GOT EOF
###############################
Domains -d www.ecample.org -d example.org
###############################Das Problem tritt bei uns nicht auf jedem Server auf.
Da /opt/pdadmin/bin/letsencrypt ein Binary ist, kann man nicht mal selber schauen, was das problem sein könnte …
Da etliche Domains HSTS verwenden, sind sie nicht mehr erreichbar.
Du kannst example.org derzeit nicht aufrufen, da die Website HSTS verwendet. Netzwerkfehler und Angriffe sind in der Regel nur vorübergehend, sodass die Seite wahrscheinlich später wieder funktioniert.
EDIT:
Bei uns hat als Übergangslösung erst einmal Folgendes geholfen:
OPENSSL_CONF=/dev/null /opt/pdadmin/bin/letsencrypt --renewMir ist das bisher nicht aufgefallen. Kann es vielleicht wieder an Debian bzw. der verwendeten curl- oder openssl-Version liegen?
Das löst aber Twilo's Problem nicht. Es wäre mal interessant, was bei Dir und bei Twilo bei "curl -V" und "openssl version" angezeigt wird. Ich denke ja, dort könnte das Problem liegen, warum Twilo den Fix machen muss.
root@XXX ~ # echo 'OS:' $(egrep '^(NAME|VERSION)=' /etc/os-release |cut -d'"' -f2 |tr "\n" ' '); echo 'SE:' $(head -qn1 /usr/local/pd-admin2/UPDATE.INF/SERIES /usr/local/pd-admin2/UPDATE.INF/VERSION); /opt/pdadmin/www/customer/customer.cgi --version |sed -e '/Bradler/d' -e 's/ version /: /' -e "s/$/ ($(file /opt/pdadmin/bin/httpd_vhosts.pl |egrep -o "ELF [0-9a-z\-]+ " |sed -e 's/ELF //g' -e 's/ \+$//'))/"
OS: Debian GNU/Linux 12 (bookworm)
SE: 8 0.498
pd-admin: v4.145 (64-bit)
root@XXX ~ # lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
root@XXX ~ # cat /etc/debian_version
12.15
root@XXX ~ # which curl
/usr/bin/curl
root@XXX ~ # curl -V
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.20 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u15
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
root@XXX ~ # /usr/local/pd-admin2/bin/curl -V
curl 8.21.0 (x86_64-pc-linux-gnu) libcurl/8.21.0 OpenSSL/3.5.7 zlib/1.3.2 brotli/1.0.7 libssh2/1.11.1 nghttp2/1.69.0 OpenLDAP/2.5.20
Release-Date: 2026-06-24
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s rtsp scp sftp smtp smtps telnet tftp ws wss
Features: alt-svc brotli HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz SSL threadsafe TLS-SRP UnixSockets
root@XXX ~ # which openssl
/usr/bin/openssl
root@XXX ~ # openssl version
OpenSSL 3.0.20 7 Apr 2026 (Library: OpenSSL 3.0.20 7 Apr 2026)
root@XXX ~ # /usr/local/pd-admin2/bin/openssl version
OpenSSL 3.5.7 9 Jun 2026 (Library: OpenSSL 3.5.7 9 Jun 2026)Hallo Twilo,
ich glaube, ich sehe den Unterschied. Bei mir (AlmaLinux, kein Fehler) zeigt /usr/local/pd-admin2/bin/openssl version -d auf einen eigenen isolierten Pfad (/usr/local/pd-admin2/openssl), getrennt von der System-OpenSSL. Kannst Du bei Dir prüfen, ob das genauso ist – und ob das Verzeichnis existiert und eine gültige openssl.cnf enthält?
Kannst Du das
/usr/local/pd-admin2/bin/openssl version -d
ls -la /usr/local/pd-admin2/openssl/ 2>&1
grep -A5 provider_sect /usr/local/pd-admin2/openssl/openssl.cnf 2>/dev/null
echo $OPENSSL_CONF
mal testen?
Guten Abend Eisenherz
root@XXX ~ # /usr/local/pd-admin2/bin/openssl version -d
OPENSSLDIR: "/usr/local/pd-admin2/openssl"
root@XXX ~ # ls -la /usr/local/pd-admin2/openssl/ 2>&1
total 928
drwxr-xr-x 5 root root 4096 20. Jul 16:13 .
drwxr-sr-x 73 root root 4096 21. Jul 21:00 ..
-rw-r--r-- 1 root root 884985 9. Mai 2017 cert.pem
drwxr-xr-x 2 root root 4096 20. Jul 16:13 certs
-rw-r--r-- 1 root root 412 20. Jul 16:13 ct_log_list.cnf
-rw-r--r-- 1 root root 412 20. Jul 16:13 ct_log_list.cnf.dist
drwxr-xr-x 2 root root 4096 20. Jul 16:13 misc
-rw-r--r-- 1 root root 12411 20. Jul 16:13 openssl.cnf
-rw-r--r-- 1 root root 12411 20. Jul 16:13 openssl.cnf.dist
drwxr-xr-x 2 root root 4096 20. Jul 16:13 private
root@XXX ~ # grep -A5 provider_sect /usr/local/pd-admin2/openssl/openssl.cnf
# referenced from the [provider_sect] below.
# Refer to the OpenSSL security policy for more information.
# .include fipsmodule.cnf
[openssl_init]
providers = provider_sect
# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
# fips = fips_sect
root@XXX ~ # echo $OPENSSL_CONF
root@XXX ~ #Guten Abend Twilo,
danke. Schade, das widerlegt tatsächlich meine bisherige Theorie. Vielleicht ist es ja doch ein Speicherproblem mit curl. Muss ich noch mal überlegen.