Kelkaj pakaĵoj de komuna gastigado kun cPanel ne ofertas AutoSSL - aŭ nur en pli multekostaj planoj. Rezulte, vi ne povas eldoni senpagan Let's Encrypt-atestilon per la cPanel-interfaco, kaj ĉiuj domajnoj estas blokitaj kun mem-subskribita atestilo. La retumilo montras la paĝon kiel "ne sekura". La solvo: akiri la atestilon mem uzante acme.sh kaj instali ĝin per la cPanel UAPI. Ĝi renoviĝos aŭtomate, sen bezono de AutoSSL.
HTTPS nun estas deviga: des pli frustrante, do, kiam via propra gastiga pakaĵo ne ofertas oportunan manieron akiri senpagan atestilon. Tio okazas pli ofte ol vi eble pensas - ekzemple, kun malmultekostaj baznivelaj pakaĵoj aŭ post planŝanĝo, kie atestilo subite ne plu estas inkludita. Tamen, ĉi tiu breĉo povas esti elegante kaj permanente fermita per nur kelkaj linioj de kodo en la ŝelo - la kompleta procezo estas priskribita sube.
1. Ensalutu per SSH
ssh -p <port> <cpanel-user>@<host>
2. Instalu acme.sh
curl https://get.acme.sh | sh -s email=du@example.com
source ~/.bashrc
3. Agordu Ni Ĉifru kiel la CA
acme.sh --set-default-ca --server letsencrypt
4. Eldoni atestilon
acme.sh --issue -d example.com -d www.example.com -w ~/public_html
5. Instalu en cPanel
acme.sh --deploy -d example.com --deploy-hook cpanel_uapi
6. Kontrolu
uapi SSL installed_hosts
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -issuer -dates
La hoko skribas la atestilon al la taŭga virtuala gastiganto per UAPI. La deplojaj agordoj estas konservitaj - de nun, cron aŭtomate renovigos kaj instalos ĉion antaŭ la eksvalidiĝo. La eldoninto devus esti "Let's Encrypt", kaj la eksvalidiĝdato devus esti proksimume 90 tagojn en la estonteco. Se la malnova, memsubskribita atestilo ankoraŭ aperas, malmola reŝargo en la retumilo kutime helpas - la antaŭa atestilo povas esti provizore konservita en kaŝmemoro.
Kelkaj retgastigantoj uzas sian propran cPanel-hokon. install_ssl kaj respondas per io simila al adminbin Cpanel/hooks2/...: exit 255. acme.sh ankoraŭ raportas "sukcese deplojita" - kaj tio kutime pravas. En ĉi tiu kazo, la hoko malsukcesas pro posta paŝo - kiel ekzemple interna sciigo aŭ sinkroniga tasko fare de la retprovizanto - ne pro la efektiva instalado.
Por domajnoj kun umlaŭtoj, acme.sh konservas la atestilon interne en la Punycode-formo (xn--…), dum la aŭtomata kongruigilo de la hoko komparas la Unikodan formon. Rezulto: "deplojita al 0 el 0 retejoj" - nenio estas instalita. La malfacila parto: acme.sh ankaŭ raportas "Sukceson" ĉi tie, do la eraro facile preteratentiĝas. Solvo: laboru rekte kun la Punycode-domajno kaj malŝaltu aŭtomatan kongruigon.:
# Punycode-Form der Domain vorher ermitteln (z. B. via idn-Tool oder Online-Konverter)
acme.sh --issue -d xn--<punycode> -d www.xn--<punycode> -w ~/public_html
export DEPLOY_CPANEL_AUTO_ENABLED='false'
acme.sh --deploy -d xn--<punycode> --deploy-hook cpanel_uapiKun SSH-aliro, vi ne bezonas AutoSSL: acme.sh eldonas la atestilon, kiu cpanel_uapiLa -Hook instalas ĝin, kaj la inkluzivita cron-tasko tenas ĝin aŭtomate ĝisdatigita. Post agordo, la senpaga HTTPS-servo funkcias kontinue memstare. Tiuj, kiuj investas la komencan penon, ŝparas al si ĉiun manan renovigon en la estonteco - kaj povas etendi la saman solvon al iu ajn plia domajno en la sama konto per ununura komando.