Manche Shared-Hosting-Pakete mit cPanel bieten AutoSSL nicht an, oder nur in höheren Tarifen. Die Folge: Über die cPanel-Oberfläche lässt sich kein kostenloses Let's-Encrypt-Zertifikat ausstellen, und alle Domains hängen auf einem selbstsignierten Zertifikat fest. Der Browser zeigt die Seite als „nicht sicher" an. Der Ausweg: das Zertifikat selbst mit acme.sh holen und über die cPanel-UAPI installieren – automatisch erneuernd, ganz ohne AutoSSL.
HTTPS ist längst Pflicht. Umso ärgerlicher, wenn ausgerechnet das eigene Hosting-Paket keinen bequemen Weg zum kostenlosen Zertifikat anbietet. Das passiert häufiger, als man denkt, etwa bei günstigen Einsteigerpaketen oder nach einer Tarifumstellung, bei der plötzlich kein Zertifikat mehr inklusive ist. Mit ein paar Zeilen auf der Shell lässt sich diese Lücke aber elegant und dauerhaft schließen – im Folgenden der komplette Weg.
1. Per SSH einloggen
ssh -p <port> <user>@example.com
2. acme.sh installieren
curl https://get.acme.sh | sh -s email=me@example.com
source ~/.bashrc
3. Let's Encrypt als CA setzen
acme.sh --set-default-ca --server letsencrypt
4. Zertifikat ausstellen
acme.sh --issue -d example.com -d www.example.com -w ~/public_html
5. Ins cPanel installieren
acme.sh --deploy -d example.com --deploy-hook cpanel_uapi
6. Prüfen
uapi SSL installed_hosts
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -issuer -dates
Der Hook schreibt das Zertifikat per UAPI auf den passenden vHost. Die Deploy-Einstellung wird gespeichert – ab jetzt erneuert und installiert der Cron alles selbstständig vor Ablauf. Der Issuer ist dabei „Let's Encrypt" und das Ablaufdatum rund 90 Tage in der Zukunft. Erscheint stattdessen noch das alte, selbstsignierte Zertifikat, hilft meist ein Hard-Reload im Browser – das vorherige Zertifikat kann kurzzeitig zwischengespeichert sein.
Auf manchen Hosts läuft ein eigener cPanel-Hook vor install_ssl und quittiert mit etwas wie adminbin Cpanel/hooks2/...: exit 255. acme.sh meldet trotzdem „successfully deployed" – und das ist korrekt. Der Hook scheitert in dem Fall an einem nachgelagerten Schritt (etwa einem internen Notify- oder Sync-Job des Hosters), nicht an der eigentlichen Installation.
Bei Domains mit Umlaut speichert acme.sh das Zertifikat intern unter der Punycode-Form (xn--…), während der Auto-Matcher des Hooks die Unicode-Form vergleicht. Ergebnis: „deployed to 0 of 0 sites" – es wird nichts installiert. Das Tückische dabei: acme.sh meldet auch hier „Success", sodass der Fehler leicht übersehen wird. Lösung: Direkt mit der Punycode-Domain arbeiten und den Auto-Modus abschalten:
python3 -c "import sys;print(sys.argv[1].encode('idna').decode())" hallöle.de
acme.sh --issue -d xn--hallle-zxa.de -d www.xn--hallle-zxa.de -w ~/public_html
export DEPLOY_CPANEL_AUTO_ENABLED='false'
acme.sh --deploy -d xn--hallle-zxa.de --deploy-hook cpanel_uapiMit SSH-Zugang ist man nicht auf AutoSSL angewiesen: acme.sh stellt das Zertifikat aus, der cpanel_uapi-Hook installiert es und der mitinstallierte Cron hält es automatisch aktuell. Einmal eingerichtet, läuft das kostenlose HTTPS dauerhaft von selbst. Wer den initialen Aufwand einmal investiert, spart sich künftig jede manuelle Verlängerung – und kann dieselbe Lösung mit einem einzigen weiteren Befehl auf jede zusätzliche Domain im selben Account übertragen.