Hvala Claudeu, jedna komanda acme.sh rešava automatsku obnovu SSL sertifikata.

Danas ujutru, drugari u tehničkom grupi su povikali: Erge, slike na technološkoj strani i na "mianzha niyi" su nestale.

Nisam tada bio za računarom i nisam mogao odmah da rešim.

Zato su i u drugoj grupi pitali šta se dešava.

Prema opisima drugara, odmah sam znao — HTTPS sertifikat CDN-a je istekao.

Da objasnim pozadinu. Imam dva sajta: javasi.dev (Ergeov Java put napredovanja) i paicoding.com (technološka strana). Slike se hostuju na Alibaba Cloud OSS + CDN i pristup slikama ide preko HTTPS-a, pa CDN mora da nosi SSL sertifikat.

Ali besplatni sertifikat sada važi samo 3 meseca, pa godišnje moraš ručno 4 puta da ga obnoviš. Za dva domena to je 8 puta.

Tok je svaki put sledeći: prvo se ulogujem u Tencent Cloud, preuzmem sertifikat sa servera, zatim uđem u konzolu Alibaba Cloud CDN-a, nalepim sertifikat i ključ, pa ih vežem za odgovarajući domen.

Moj server je na Tencent Cloud-u; ranije je bio na Alibaba Cloud-u, ali su mi uslužnost degradirali pa sam prešao. Ali OSS i CDN nisam pomerio, jer je migracija slika previše komplikovovana — desetine hiljada slika, desetine GB; samo preuzimanje i otpremanje bi trajalo satima.

Učestalost nije visoka, ali svaki put je naporno i lako se zaboravi.

Brzo sam otvorio računar i nadoknadio sertifikat.

Posle dopune pomislio sam: da li bi ovo moglo jednom za svagda da se automatizuje?

Već davno sam mislio da iskoristim automatizaciju Codex-a, ali uvek mi se činilo da to nije to. Zato što je Codex instaliran lokalno, a za rad sa Tencent Cloud i Alibaba Cloud konzolama ima nekoliko slojeva u sredini — već pri pomisli glava boli, pa sam stalno odlagao.

Ali danas više nisam mogao da izdržim, pa sam pitao Claude-a da li može ovo da se automatizuje.

U početku sam mislio na stari pristup — preuzeti sertifikat sa Tencent Cloud-a i zatim preko browsera raditi sa Alibaba Cloud konzolom, slično OpenClaw-ovom hostovanom servisu.

Ali Claude mi je dao jedno superprosto rešenje, toliko prosto da nisam mogao da poverujem.

Otvorio sam QoderWork da ponovo potvrdim, mišljenja su skoro ista. Izgleda da je zaista izvodljivo.

Jedna komanda: sertifikat se automatski otpremi na Alibaba Cloud, automatski veže za CDN domen, a sve naredne obnove idu bez intervencije.

Odmah sam krenuo da izvršim. I uselo.

Ovaj članak deli kompletan proces, uključujući šta je acme.sh, koja je razlika između ECC i RSA i kako radi Alibaba Cloud deploy hook.

Ako ste ranije koristili usluge sertifikata i hosting usluge Alibaba Cloud-a, ovaj pristup vam godišnje može uštedeti preko 2000 juana.

Hvala Claudeu!

01. Jedna komanda i gotovo

Da krenem od zaključka — jezgro je nekoliko linija:

export Ali_Key="tvoj AccessKeyId"
export Ali_Secret="tvoj AccessKeySecret"
export DEPLOY_ALI_CDN_DOMAIN="cdn.tobebetterjavaer.com"

acme.sh --deploy -d tobebetterjavaer.com --ecc --deploy-hook ali_cdn

Posle toga idi u Alibaba Cloud CDN sertifikate da potvrdiš — ažuriranje je uspelo.

Mili moji, sa ovako prostim rešenjem, ja sam pet-šest godina glupo radio ručno.

Alibaba Cloud ovo ne pominje u dokumentaciji.

Biznis model Alibaba Cloud-a je: jedan SSL sertifikat na 6 meseci košta 1873.5 juana; godišnja usluga hostovanja sertifikata košta 270 juana.

A naše rešenje je besplatno i potpuno hostovano.

02. Šta je zapravo acme.sh

acme.sh je ACME klijent napisan čistim shell skriptama; ne zavisi od Python-a, ne zavisi od Go-a, dovoljan je jedan bash.

ACME je skraćenica od Automatic Certificate Management Environment — automatizovani protokol za upravljanje sertifikatima koji je definisao Let's Encrypt.

Laički: acme.sh za nas automatski traži besplatan HTTPS sertifikat od CA (autoriteta za sertifikate), automatski ga obnavlja i može da ga automatski deploy-uje na razne cloud servise.

Pored Let's Encrypt, podržava ZeroSSL, Buypass, Google Trust Services.

Na mom serveru koristim litessl.com, što se vidi iz izlaza acme.sh --list.

Sve je ECC algoritam, sve izdato preko litessl, sve besplatno.

Ovaj alat na GitHub-u ima 41k+ zvezda (stanje na 2026-04-12) i najpopularnije je besplatno rešenje za sertifikate, bez konkurencije.

Instalacija je vrlo prosta — jedna linija:

curl https://get.acme.sh | sh

Posle instalacije automatski se u crontab dodaje cron posao koji svakog dana u rano jutro proverava sertifikate i automatski obnavlja one koji uskoro ističu. To znači da posle instalacije uglavnom ne moraš da brineš.

acme.sh ima i nekoliko čestih komandi:

# Pregled svih sertifikata pod upravljanjem
acme.sh --list

# Ručna obnova određenog sertifikata
acme.sh --renew -d tobebetterjavaer.com --ecc

# Prisilna obnova (iako još nije istekao)
acme.sh --renew -d tobebetterjavaer.com.com --ecc --force

# Brisanje zapisa o sertifikatu (ne briše fajl na disku)
acme.sh --remove -d tobebetterjavaer.com --ecc

# Pregled verzije acme.sh
acme.sh --version

U normalnim uslovima nije potrebna ručna obnova — cron posao to radi sam. Ali ako si upravo konfigurisao deploy hook i želiš odmah da testiraš efekat, možeš sa --force da ga pokreneš.

03. Kompletan prompt i pristup

Podeliću prompt koji sam dao Claude-u; ako imate slične zahteve za automatizacijom, možete pratiti ovaj pristup:

E ovako: na Alibaba Cloud-u imam dva CDN sertifikatna servisa i svaki put moram ručno da ih održavam. Trenutni tok je: na serveru se automatski generiše sertifikat za *.tobebetterjavaer.com, ja ga preuzmem lokalno, zatim se ulogujem u Alibaba Cloud cdn.console.aliyun.com, otpremim sertifikat, pa ga vežem za domen cdn.tobebetterjavaer.com. Želim da proverim da li postoji automatsko rešenje koje bi, nakon što acme.sh na serveru generiše sertifikat, pozvalo hook servis Alibaba Cloud-a, obavilo otpremanje sertifikata i vezivanje domena, i konačno potvrdilo da li je proradilo.

Ključno je jasno opisati trenutni proces — kako sada radim, šta radim u svakom koraku, i šta je konačni cilj.

Sa tim informacijama Claude je prvo potražio listu deploy hook-ova acme.sh-a, potvrdio da hook ali_cdn zaista postoji, a zatim dao kompletan plan.

Citav proces nije trajao ni minut.

A da sam sam listao wiki dokumentaciju acme.sh-a, možda ni pola sata ne bih našao — jer nisam odmah znao da treba da tražim ključnu reč "deploy hook"; u glavi mi je rešenje bilo "upravljanje Alibaba Cloud konzolom preko browsera".

Tu je najveća vrednost saradnje sa AI-jem: AI nas izvlači iz sopstvenog obrasca razmišljanja i nudi put koji sami ne bismo videli.

04. Zamke na koje sam naleteo

Ali pri prvom pokretanju sam naleteo.

Claude je u početku dao komandu:

acme.sh --deploy -d "*.tobebetterjavaer.com" --deploy-hook ali_cdn

Izlaz je prijavio grešku:

The domain '*.tobebetterjavaer.com' is not a cert name.
Cannot find path: '.sh/*.tobebetterjavaer.com'

Razlog je što acme.sh pri čuvanju sertifikata lokalno koristi ime glavnog domena za direktorijum, bez zvezdice. A ako je sertifikat izdat ECC algoritmom (što je sada podrazumevano), direktorijum dobija i sufiks _ecc.

Prvo pogledajmo šta postoji lokalno:

ls ~/.acme.sh/ | grep tobebetterjavaer
# Izlaz: tobebetterjavaer.com_ecc

Zaista, ime direktorijuma je tobebetterjavaer.com_ecc, a ne *.tobebetterjavaer.com.

Još jednom sa acme.sh --list potvrdimo podatke o sertifikatu:

Main_Domain           KeyLength  SAN_Domains
tobebetterjavaer.com  "ec-256"   *.tobebetterjavaer.com

Main_Domain je tobebetterjavaer.com, SAN sadrži *.tobebetterjavaer.com, što znači da je sertifikat wildcard i pokriva sve poddomene.

Zato je ispravna komanda:

acme.sh --deploy -d tobebetterjavaer.com --ecc --deploy-hook ali_cdn

Dve ključne stvari: -d prima glavni domen bez zvezdice; --ecc govori acme.sh-u da traži _ecc direktorijum.

Ova zamka nije velika, ali ako je ne znaš, zaglaviš.

Kasnije sam razmislio: razlog što Claude u prvom pokušaju nije dao tačnu komandu jeste što, intuitivno, wildcard sertifikat bi trebalo referencisati preko *.xxx.com — ipak tako ga prijavljujemo. Ali interni model acme.sh-a se razlikuje od intuicije: on koristi glavni domen i sufiks da organizuje direktorijume.

Ovakvi "izgleda da bi trebalo, a opet ne valja" problemi se mogu rešiti i samostalnim debug-om, ali Claude je čim video grešku odmah locirao uzrok i usput me naučio kako da proverim ECC naspram RSA — ta efikasnost je zaista visoka.

Iskreno, saradnja sa Claude-om na ovakvim problemima održavanja je pomalo drugačija od pisanja koda. U kodu Claude može da piše umesto tebe, ali kod održavanja ti moraš sam da izvršavaš komande na serveru, čitaš izlaz i vraćaš mu ga.

04. Šta je ECC

Da objasnimo i ECC sertifikate.

Srž HTTPS sertifikata je par ključeva — javni i privatni. Algoritam za generisanje ključeva je uglavnom RSA ili ECC.

RSA je veteran, u upotrebi decenijama, sa dobrom kompatibilnošću, ali su ključevi dugi. Obično su potrebne 2048 ili čak 4096 bita za bezbednost; fajl ključa je velik i pri handshake-u se prenosi više podataka.

ECC je skraćenica od Elliptic Curve Cryptography — kriptografija eliptičkih krivih. Kraćim ključem postiže istu bezbednost.

Koliko kraćim?

256-bitni ECC ključ odgovara 3072-bitnom RSA po bezbednosti. Veličina ključa se razlikuje deset puta.

Za CDN situaciju, ova razlika se direktno vidi u brzini TLS handshake-a. Kada korisnik prvi put pristupi slici, browser i CDN granični čvor moraju da obave handshake i razmene sertifikate i ključeve. ECC sertifikat prenosi manje podataka, handshake je brži, što je naročito povoljno za mobilne uređaje na slaboj mreži.

Nova verzija acme.sh podrazumevano koristi ECC (ec-256), zato lokalni direktorijum nosi sufiks _ecc.

Iz mog acme.sh --list vidi se da je KeyLength svih sertifikata ec-256, što potvrđuje ECC.

Ako želiš da proveriš da li je sertifikat ECC ili RSA, pogledaj conf fajl:

cat ~/.acme.sh/tobebetterjavaer.com_ecc/tobebetterjavaer.com.conf | grep Le_Keylength
# Le_Keylength='ec-256'  → ECC
# Le_Keylength='2048'    → RSA

Ako počinje sa ec-, ECC je; ako su samo brojevi, RSA.

Neko će možda pitati: kako ECC stoji sa kompatibilnošću?

Godina je 2026, svi glavni browser-i i operativni sistemi podržavaju ECC.

Još jedan koncept je "wildcard sertifikat", koji ćemo takođe objasniti.

Wildcard sertifikat *.tobebetterjavaer.com pokriva sve poddomene drugog nivoa — cdn.tobebetterjavaer.com, api.tobebetterjavaer.com, www.tobebetterjavaer.com i dr. Ali ne pokriva goli domen tobebetterjavaer.com niti poddomene trećeg nivoa a.b.tobebetterjavaer.com.

Zato se pri izdavanju sertifikata obično goli domen i wildcard upisuju zajedno:

acme.sh --issue --dns dns_dp \
  -d tobebetterjavaer.com \
  -d '*.tobebetterjavaer.com' \
  --keylength ec-256

Tako jedan sertifikat pokriva i goli domen i sve poddomene drugog nivoa — zgodno.

06. Kako radi deploy hook Alibaba Cloud-a

Ovo je ključni deo automatizacije.

acme.sh u sebi ima desetine deploy hook-ova koji pokrivaju glavne cloud provajdere. ali_cdn je specijalno za Alibaba Cloud CDN.

https://github.com/acmesh-official/acme.sh/wiki/deployhooks

Pri izvršenju --deploy-hook ali_cdn, acme.sh radi tri stvari:

Prvo, čita lokalne fajlove sertifikata. acme.sh u direktorijumu ~/.acme.sh/tobebetterjavaer.com_ecc/ traži fullchain.cer (kompletni lanac sertifikata) i tobebetterjavaer.com.key (privatni ključ), a zatim poziva API Alibaba Cloud SSL sertifikatnog servisa da otpremi sertifikat. Pri otpremanju automatski generiše ime sertifikata, u formatu sličnom cert-cdn.tobebetterjavaer.com-6.

Drugo, poziva API Alibaba Cloud CDN-a i vezuje novootpremljeni sertifikat na domen naveden u DEPLOY_ALI_CDN_DOMAIN. Ovaj korak zamenjuje stari sertifikat trenutno vezan za domen; Alibaba Cloud automatski distribuira novi sertifikat na sve CDN čvorove.

Treće, upisuje Ali_Key, Ali_Secret, DEPLOY_ALI_CDN_DOMAIN u conf fajl tog sertifikata, dodajući prefiks SAVED_ (na primer SAVED_DEPLOY_ALI_CDN_DOMAIN). Pri narednim obnavljanjima koja pokrenu hook, acme.sh automatski čita ove promenljive iz conf fajla, pa ne moraš ponovo da ih export-uješ.

Sva tri koraka se obavljaju u jednoj komandi, za nekoliko sekundi.

Promenljive se čuvaju po sertifikatu, nisu globalno deljene.

U conf fajlu tobebetterjavaer.com_ecc stoji cdn.tobebetterjavaer.com; u paicoding.com_ecc stoji cdn.paicoding.com. Pri obnavljanju svaki čita svoje, bez međusobnog ometanja.

Isprva sam se plašio da će konfiguracija drugog domena pregaziti prvi. Claude mi je zadao jednu komandu za proveru:

grep SAVED_DEPLOY_ALI_CDN_DOMAIN \
  com_ecc/tobebetterjavaer.com.conf \
  paicoding.com.conf

Dva reda izlaza, svaki pokazuje na svoj CDN domen — jasno.

Potrebne AccessKey dozvole su takođe jednostavne, samo dve: AliyunYundunCertFullAccess (za otpremanje sertifikata) i AliyunCDNFullAccess (za vezivanje domena).

Još par reči o bezbednosti.

Preporučujem da u RAM konzoli Alibaba Cloud-a kreirate poseban podnalog sa samo ove dve dozvole; nemojte koristiti AccessKey glavnog naloga. Ako server bude kompromitovan, podnalog može najviše da dira SSL sertifikate i CDN, bez uticaja na ostale resurse. Princip minimalnih dozvola se mora poštovati.

Pored toga, Ali_Key i Ali_Secret se posle prvog export-a upisuju u conf fajl od strane acme.sh-a i nakon toga nije potrebno ponovo da ih export-ujete. Zato ih nemojte stavljati u .bashrc ili .zshrc.

07. I drugi domen rešen u isto vreme

Nakon što je tobebetterjavaer.com proradio, uz to sam rešio i paicoding.com.

Pošto su Ali_Key i Ali_Secret pri prethodnom deploy-u već zapamćeni u acme.sh-u, sada samo treba promeniti CDN domen:

export DEPLOY_ALI_CDN_DOMAIN="cdn.paicoding.com"
acme.sh --deploy -d paicoding.com --ecc --deploy-hook ali_cdn

Prolazi za sekund. "Domain cdn.paicoding.com certificate has been deployed successfully" — poznata poruka o uspehu.

Podaci o sertifikatima oba domena vide se u Alibaba Cloud konzoli; status je normalan, rok važenja je osvežen do juna.

Usput, u acme.sh --list sam primetio i čudan zapis — *.paicoding.com se pojavljuje zasebno, sa SAN no.

Claude kaže da je to zaostali indeks od ranijeg izdavanja sertifikata; zapravo na disku postoji samo jedan sertifikat (onaj paicoding.com_ecc). Ovaj zaostali indeks može se obrisati sa acme.sh --remove -d '*.paicoding.com' --ecc, bez uticaja na normalnu upotrebu.

Uputom sam otkrio još jedan zanimljiv detalj — cdn.paicoding.com prikazuje glavni domen *.paicoding.com, dok cdn.tobebetterjavaer.com prikazuje tobebetterjavaer.com.

Claude objašnjava da je to u vezi sa redosledom -d parametara pri izdavanju sertifikata.

Sertifikat na dva mesta beleži domen: Subject CN (samo jedan domen) i SAN (može ih biti više).

Browser i CDN zapravo proveravaju SAN, ali Alibaba Cloud konzola u koloni "glavni domen" čita Subject CN.

Pri izdavanju sertifikata, prvi -d parametar se upisuje u Subject CN. za tobebetterjavaer.com sam tada prvo upisao goli domen pa onda wildcard, pa je CN goli domen; za paicoding.com sam prvo upisao wildcard, pa je CN *.paicoding.com.

Funkcionalno nema razlike, čisto je pitanje prikaza. Ako te nervira i želiš da ujednačiš, pre sledeće obnove obriši i ponovo izdaj, tako da goli domen bude prvi -d.

Takvi detalji se bez pitanja ne bi znali.

Sam prelistavanjem dokumentacije teško bih našao odgovor, jer se Subject CN retko pominje u popularnim HTTPS tutorijalima — to je više koncept iz PKI (javne ključne infrastrukture). Ali za nas koji radimo sa ovim stvarima, kad na konzoli iznenada iskoči drugačiji glavni domen, prva pomisao je "da li sam negde pogrešio". Claude u jednom potezu objasni uzrok i posledicu, pa čovek mirno spava.

08. Verifikacija i završetak

Posle deploy-a ne smemo samo tako da ostavimo; treba proveriti da li su granični čvorovi zaista prešli na novi sertifikat.

echo | openssl s_client -servername cdn.tobebetterjavaer.com \
  -connect cdn.tobebetterjavaer.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

Pogledaj da li je notAfter datum isteka novog sertifikata. Na Alibaba Cloud CDN-u od slanja do aktiviranja na čvorovima obično prođe nekoliko do desetak minuta; ako pri prvom proveravanju vidite stari, nemojte paničiti.

Na kraju potvrdimo da li će obnova automatski pokrenuti deploy:

grep Le_DeployHook ~/.acme.sh/tobebetterjavaer.com_ecc/tobebetterjavaer.com.conf
# Izlaz: Le_DeployHook='ali_cdn'

Ako vidite ali_cdn, znači da je zakacen. Odsad acme.sh cron svakodnevno proverava sertifikate, blizu isteka automatski obnavlja, a posle uspešne obnove automatski gura novi sertifikat na Alibaba Cloud i vezuje ga — bez ljudskog prisustva.

Ovim se završava noćna mora "ručnog ažuriranja na tri meseca".

Na kraju da sumiram kompletan tok ovog automatizovanog rešenja:

Od početka do kraja, bez ljudskog uplitanja.

Ako je neko u sličnoj situaciji — server kod jednog clouda, CDN kod drugog, sertifikati upravljani acme.sh-om — slobodno prekopirajte ovo rešenje.

Pored ali_cdn, acme.sh u sebi ima i druge deploy hook-ove: ali_dcdn (Alibaba Cloud Full Site Acceleration), tencent_cdn (Tencent Cloud CDN), cloudflare, aws_s3 i dr. Princip je isti: podesi AccessKey, navedi domen, jedna --deploy komanda rešava stvar.

Ako je čisto Tencent Cloud okruženje (i server i CDN kod Tencent-a), koristi tencent_cdn hook; možete reuse i AccessKey.

ending

Jedna komanda rešila problem koji me mučio pet-šest godina.

Nije da je rešenje komplikovano, nego uopšte nisam znao da acme.sh ima ali_cdn deploy hook.

Alibaba Cloud mi to neće reći. Oni imaju plaćeni SSL sertifikatni servis — godišnje 270; sertifikat na šest meseci 1873.5.

[Najskuplji trošak nije novac, nego neznanje. A imati top Agent je najveći bonus koji nam AI era donosi]

Kad u glavi imaš ideju, kad te muči ponavljajući posao, pitaj Claude Opus — možda ti dati neočekivano rešenje.

Vidimo se u sledećem.