Jinsi ya kupata wildcard certificate kwa Certbot DNS-01

Kwa nini cheti cha wildcard kinahitaji DNS-01

Cheti cha wildcard hufunika kila subdomain ya ngazi ya kwanza ya domain: *.example.com inalingana na app.example.com, blog.example.com, na jina lingine lolote lenye lebo moja. Let’s Encrypt hutoa vyeti vya wildcard kupitia changamoto ya DNS-01 pekee, kwa hivyo Certbot lazima ithibitishe udhibiti wa DNS ya domain kwa kuchapisha rekodi ya TXT kwenye _acme-challenge.example.com. Changamoto ya HTTP-01 haiwezi kufaa, kwa sababu kuhudumia faili ya token kunathibitisha udhibiti wa hostname moja tu, ile ambayo seva ya uthibitishaji ilichota faili kutoka kwayo. Wildcard ni dai kuhusu kila jina linalowezekana katika ngazi moja chini ya domain, na rekodi pekee ya umma inayowakilisha namespace nzima ni DNS yenyewe.

Sharti hilo moja huamua kila kitu kingine kwenye ukurasa huu. Ili kupita DNS-01 lazima uweze kuunda rekodi za TXT katika zone ya domain, au katika zone tofauti ya uthibitishaji ambayo _acme-challenge inaelekeza kwa kutumia CNAME (imefafanuliwa hapa chini), ama kwa mkono au kupitia API (application programming interface) ya mtoa huduma wako wa DNS. Njia ya kufanya kwa mkono hufanya kazi mara moja kisha hushindwa wakati wa kusasisha (renewal), kwa sababu dhahiri iliyoonyeshwa hapa chini. Njia ya API, kupitia plugin ya DNS ya Certbot, husasisha bila kuhitaji usimamizi, na ndiyo usanidi unapaswa kuishia nao.

Hii ni sura ya wildcard ya miongozo yetu ya Certbot. Vyeti vya kawaida vya hostname moja, usanidi wa seva ya web na sheria za port 80 zimefafanuliwa katika Certbot na nginx kwenye Ubuntu 24.04 na Certbot na Apache kwenye Ubuntu 24.04.

Jinsi rekodi ya TXT ya _acme-challenge inavyofanya kazi

Certbot inapoomba *.example.com, Let's Encrypt hujibu kwa token nasibu. Certbot huunganisha token hiyo na ufunguo wa akaunti yako ya ACME (automatic certificate management environment), huhashisha matokeo kwa SHA-256, kisha hutengeneza thamani fupi ya maandishi. Thamani hiyo lazima ionekane kama rekodi ya TXT kwenye _acme-challenge.example.com. Kisha Let's Encrypt huuliza name server zenye mamlaka za domain yako kutoka kwenye miundombinu yake. Ikiwa rekodi inayosomwa inalingana na thamani inayotarajiwa, umethibitisha kuwa unadhibiti zone hiyo. Udhibiti wa zone hiyo hukubaliwa kuwa udhibiti wa kila name iliyo chini yake.

Maelezo mawili husababisha failures nyingi:

• Kuomba example.com na *.example.com kwenye certificate moja kunamaanisha challenges mbili tofauti. Rekodi zote mbili za TXT zinapatikana kwenye name moja, _acme-challenge.example.com. Zote lazima ziwepo kwa wakati mmoja. Kuongeza rekodi ya pili ni sahihi. Kubadilisha ya kwanza na ya pili husababisha challenge ya kwanza ishindwe.
• Validation husoma kutoka kwenye server zako zenye mamlaka. Hata hivyo, control panel za provider zinaweza kuchukua dakika moja au zaidi kusambaza rekodi mpya kwenye server hizo. Kagua kutoka nje kabla ya kuruhusu validation ianze:

dig +short TXT _acme-challenge.example.com @1.1.1.1

Ikiwa amri hiyo itaonyesha thamani ambayo Certbot iliomba, validation inaweza kufanikiwa. Ikiwa haitaonyesha chochote, subiri kisha uiendeshe tena.

Ione ikifanya kazi mara moja: hali ya mwongozo

Hali ya mwongozo inakuhitaji uhariri rekodi ya DNS mwenyewe. Hii ndiyo njia bora ya kuelewa utaratibu kabla ya kuufanya uwe wa kiotomatiki:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

Alama za nukuu zinazozunguka wildcard huzuia shell yako kuichukulia * kama muundo wa jina la faili. Certbot husitisha mchakato na kuonyesha maelekezo:

Please deploy a DNS TXT record under the name:
_acme-challenge.example.com.
with the following value:
Jx9mQ2wLr8vTn5cKp0aYdG3hB7fZs4eN1oiRuXqMk6E

Unda rekodi hiyo ya TXT kwenye paneli ya mtoa huduma wako wa DNS. Thibitisha kuwa inaonekana kwa kutumia amri ya dig iliyo hapo juu. Kisha bonyeza Enter. Kwa sababu utekelezaji huu unaomba domain tupu na wildcard, Certbot huonyesha ombi hilo mara mbili. Weka rekodi zote mbili hadi issuance ikamilike. Utekelezaji ukifaulu, huisha kwa mistari hii inayojulikana:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem

Kwa nini mode ya manual haiwezi kujisasisha

Kila renewal ni challenge mpya yenye token mpya, kwa hiyo thamani ya TXT hubadilika kila mara. Record uliyoweka leo haitatumika baada ya siku 60. Timer ya renewal huendesha Certbot bila usimamizi wa mtu mara mbili kwa siku, na hakuna mtu aliye kwenye kibodi wa kuweka thamani mpya. Kwa hiyo, certificate iliyotolewa kwa manual mode hushindwa kufanya renewal na kutoa error hii:

Failed to renew certificate example.com with error: The manual plugin is not
working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with
--manual-auth-hook when using the manual plugin non-interactively.')

Unaweza kutimiza sharti hilo kwa kuandika scripts za --manual-auth-hook zinazotumia API ya provider wako wa DNS. Hata hivyo, wakati huo utakuwa unatengeneza upya DNS plugin kwa mkono. Tumia manual mode kujifunza mtiririko huo, au kwa operesheni ya mara moja kwenye domain ambayo DNS yake bado huwezi ku-automate. Weka reminder kabla ya siku ya 90, kwa sababu Let's Encrypt haitumi tena barua pepe za expiry. Kwa kila hali nyingine, tumia plugin.

Njia ya plugin: certbot-dns-cloudflare kwenye Ubuntu 24.04

Plugin ya DNS huhifadhi credential ya API ya mtoa huduma wako wa DNS na hushughulikia mchakato wote wa rekodi ya TXT yenyewe, wakati wa kutoa cheti na tena wakati wa kila renewal. Cloudflare ndiyo mfano unaotumika hapa kwa sababu ndiyo plugin ya mtoa huduma ambayo watu wengi wanahitaji, na imejumuishwa kwenye Ubuntu.

Miongozo yetu ya Certbot inapendekeza vifurushi vya apt kwenye Ubuntu 24.04, na msimamo huo unatumika pia kwa Cloudflare:

sudo apt update
sudo apt install certbot python3-certbot-dns-cloudflare

Kuna maelezo muhimu kuhusu matoleo. Archive ya 24.04 inasafirisha plugin hii katika toleo 2.0.0 pamoja na Certbot 2.9.0; apt policy python3-certbot-dns-cloudflare huonyesha toleo lako. Tofauti hii haina madhara, na API tokens zenye scope hufanya kazi kwa sababu library ya python3-cloudflare iliyo kwenye 24.04 ni toleo 2.11.1, ambalo ni jipya kuliko toleo 2.3.1 linalohitajika na plugin kwa ajili ya token support. Kwenye matoleo ya zamani ya Ubuntu, library hiyo ilikuwa ya zamani sana kuweza kutumia tokens. Hapo ndipo zinapotoka warnings unazoweza kupata mtandaoni kwamba apt plugin inalazimisha matumizi ya Global API Key. Kwenye 24.04 warnings hizo hazitumiki tena.

Kwenye dashboard ya Cloudflare, tengeneza API token yenye scope maalumu, si Global API Key: My Profile, kisha API Tokens, halafu Create Token, ukiweka permission moja tu ya Zone / DNS / Edit na kuizuia kwenye zone moja unayotoa cheti. Iweke kwenye faili ambayo root pekee anaweza kuisoma:

sudo mkdir -p /root/.secrets
sudo tee /root/.secrets/cloudflare.ini > /dev/null <<'EOF'
dns_cloudflare_api_token = paste_your_scoped_token_here
EOF
sudo chmod 600 /root/.secrets/cloudflare.ini

Certbot hukagua mode ya faili na kutoa warning kuhusu Unsafe permissions on credentials configuration file ikiwa faili inaweza kusomwa na watumiaji wengine. Sasa toa cheti:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

Plugin huunda rekodi za TXT kupitia API, husubiri muda mfupi wa propagation, huruhusu validation kuendeshwa, kisha hufuta rekodi hizo tena. Ikiwa name servers za zone yako zinachelewa kupokea mabadiliko, ongeza muda wa kusubiri kwa kutumia --dns-cloudflare-propagation-seconds 60. Cheti huwekwa kwenye /etc/letsencrypt/live/example.com/, kisha uelekeze nginx au Apache kwenye fullchain.pem na privkey.pem, kama miongozo ya msingi inavyoonyesha, ukiwemo deploy hook.

Ikiwa plugin ya mtoa huduma wako haipo kwenye apt

Archive ya 24.04 ina plugins kwa watoa huduma wachache tu, ikiwemo Cloudflare, Route 53, DigitalOcean na interface ya kawaida ya RFC 2136. Tekeleza apt search certbot-dns ili kuona orodha hiyo. Ikiwa mtoa huduma wako hayupo, hapa ndipo ushauri wetu wa kutumia apt kwanza unapobadilika: sakinisha Certbot na plugin kutoka snap badala yake, na uondoe Certbot ya apt kwanza ili timers mbili za kusasisha zisigombanie /etc/letsencrypt:

sudo apt remove certbot python3-certbot-dns-cloudflare
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-yourprovider

Plugin ya snap huunganishwa na Certbot ya snap pekee; haiwezi kupanua ile ya apt, ndiyo sababu usakinishaji huu miwili haupaswi kuwepo pamoja. Na ikiwa host wako wa DNS haitoi API yoyote, una chaguzi tatu za kweli. Unaweza kuhamisha DNS ya domain kwa mtoa huduma aliye na API. Unaweza kuendesha name server yako mwenyewe na kuelekeza plugin ya rfc2136 kwake. Au unaweza kubaki na host wako wa sasa wa DNS na kuongeza CNAME ya mara moja kutoka _acme-challenge.example.com kwenda kwenye zone ya uthibitishaji ambayo ina API, kama vile huduma ya acme-dns iliyopangishwa au seva ya acme-dns unayoendesha wewe mwenyewe. Let’s Encrypt hufuata CNAME hiyo wakati wa uthibitishaji, kwa hivyo rekodi za TXT hukaa kwenye zone iliyokabidhiwa na zone yako kuu haibadiliki tena.

Renewal: thibitisha sasa, si baada ya siku 60

Certbot huhifadhi jinsi kila certificate ilivyotolewa katika /etc/letsencrypt/renewal/example.com.conf, pamoja na authenticator = dns-cloudflare na path ya credentials. Kwa hiyo, timer ya kawaida inayoendesha mara mbili kwa siku hu-renew certificate hiyo bila msaada wako. Fanya majaribio ya mchakato mzima dhidi ya mazingira ya staging:

sudo certbot renew --dry-run

Mafanikio yanaonyesha kuwa credential inafanya kazi na validation imekamilika kutoka mwanzo hadi mwisho. Renewal halisi baada ya siku 60 itafuata mchakato huo huo. Kuna hatua mbili za kufuatilia ambazo unapaswa kufanya leo. Kwanza, certificate iliyorenew kwenye disk haibadili chochote hadi web server iipakie upya. Kwa hiyo, weka deploy hook iliyoelezwa katika miongozo ya nginx na Apache. Pili, linda file la credentials: mtu yeyote anayeweza kulisoma anaweza kuhariri DNS zone yako. Hilo linatosha kuelekeza upya mail yako au kukamilisha DNS-01 challenges zake mwenyewe. Weka file hilo kwa mode 600 chini ya /root, punguza token itumike kwenye zone moja tu, na ibadilishe ukihisi kuwa imevuja.

Wakati ambapo huhitaji wildcard

Wildcard ndiyo chaguo sahihi kwa subdomain nyingi, au kwa subdomain ambazo huwezi kuzitabiri. Si chaguo-msingi sahihi kwa kila hali nyingine.

• Subdomain moja, au chache zinazojulikana: certificate ya kawaida ya SAN (subject alternative name) ni rahisi zaidi. certbot --nginx -d example.com -d www.example.com -d app.example.com inashughulikia hadi majina 100 kupitia HTTP-01 ya kawaida, na credential ya DNS API haiwahi kuhifadhiwa kwenye seva.
• Wildcard hulingana na label moja tu. *.example.com haijumuishi example.com bila subdomain, ndiyo sababu amri zilizo hapo juu zinaomba zote mbili, na pia haijumuishi a.b.example.com; hilo linahitaji *.b.example.com.
• Private key moja hutumiwa na kila subdomain. Mashine inayoihifadhi ikivamiwa, kila jina linaloshughulikiwa na wildcard huathirika mara moja.
• Ikiwa Traefik inakamilisha TLS (transport layer security) kwa containers zako, huhitaji Certbot kabisa: Traefik huomba vyeti vya wildcard yenyewe kupitia DNS-01, kwa kutumia aina hiyo hiyo ya token ya provider.

Wildcard huwa na manufaa ya kweli kwa subdomain za kila mteja au kila app zinazoundwa kwa kasi ambayo ni kubwa kuliko unavyotaka kuomba vyeti upya, na kwa hosts za ndani zisizo na public port 80, kama vile huduma zinazofikiwa tu kupitia VPN ya WireGuard. DNS-01 haiunganishi kamwe na host inayothibitishwa, kwa hiyo hata mashine iliyo private kabisa inaweza kuwa na certificate inayoaminika hadharani.

FAQ

Je, Certbot inaweza kutoa cheti cha wildcard kwa kutumia HTTP-01?

Hapana. HTTP-01 inathibitisha udhibiti wa hostname moja, kwa sababu seva ya uthibitishaji huchota faili ya token kutoka jina hilo kamili. Wildcard hufunika kila jina la ngazi ya kwanza chini ya domain, kwa hivyo Let’s Encrypt inahitaji changamoto ya DNS-01 kwa ajili yake, na authenticators za --nginx, --apache, --webroot na --standalone zote hutegemea HTTP. Njia pekee ni rekodi ya TXT kwenye _acme-challenge.example.com (au kwenye zone iliyokabidhiwa kwa CNAME), iliyowekwa kwa mkono au na plugin ya DNS.

Je, cheti cha wildcard hufunika root domain?

Hapana. Wildcard inalingana na lebo moja tu, kwa hivyo *.example.com hufunika www.example.com lakini si example.com, na si a.b.example.com. Omba majina yote mawili kwenye cheti kimoja kwa kutumia -d example.com -d '*.example.com'. Hilo huunda changamoto mbili, na rekodi zote mbili za TXT hukaa kwenye jina lilelile la _acme-challenge.example.com, kwa hivyo ongeza rekodi ya pili bila kufuta ya kwanza.

Kwa nini cheti changu cha wildcard hakisasishwi kiotomatiki?

Kwa sababu kilitolewa kwa kutumia --manual. Kila usasishaji unahitaji thamani mpya kabisa ya TXT, na timer ya kiotomatiki haina njia ya kuiweka, kwa hivyo usasishaji husimama na kosa la An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively. Toa cheti upya kwa kutumia plugin ya DNS kama vile certbot-dns-cloudflare, au toa scripts za --manual-auth-hook na --manual-cleanup-hook zinazohariri rekodi kupitia API ya mtoa huduma wako.

Rekodi ya TXT ya _acme-challenge huchukua muda gani kuonekana?

Inategemea mtoa huduma wako wa DNS: kuanzia sekunde chache hadi dakika kadhaa. Uthibitishaji husoma seva za mamlaka (authoritative servers) za zone yako, kwa hivyo kagua na dig +short TXT _acme-challenge.example.com @1.1.1.1 na usubiri hadi thamani inayotarajiwa ionekane kabla ya kuendelea na utekelezaji wa mkono. Ukiwa na plugin, ongeza muda wa kusubiri kupitia chaguo la propagation la plugin hiyo, kwa mfano --dns-cloudflare-propagation-seconds 60, ikiwa uthibitishaji utaripoti kuwa rekodi haikupatikana.

Je, cheti cha wildcard hakina usalama kama cheti cha kawaida?

Cryptography ni ileile. Tofauti ziko kwenye utendaji: private key moja hufunika kila subdomain, kwa hivyo uvunjaji wa usalama unaweza kuathiri zaidi, na kitambulisho cha API ya DNS ambacho otomatiki inahitaji ni siri nyeti iliyohifadhiwa kwenye seva. Ikiwa unaendesha subdomains chache zinazojulikana, cheti cha SAN huepuka wasiwasi wote, na ndipo mwongozo huu unapopendekeza kuacha kutumia wildcard.