Jinsi ya kupata wildcard certificate kwa Certbot DNS-01

Kwa nini wildcard certificate inahitaji DNS-01

Wildcard certificate inashughulikia subdomain zote za kiwango cha kwanza za domain: *.example.com inalingana na app.example.com, blog.example.com, na jina lingine lolote lenye label moja chini yake. Let’s Encrypt hutoa wildcard certificates kupitia challenge ya DNS-01 pekee, kwa hiyo Certbot lazima ithibitishe udhibiti wa DNS ya domain kwa kuchapisha TXT record kwenye _acme-challenge.example.com. Challenge ya HTTP-01 haiwezi kutumika, kwa sababu kuhudumia token file kunathibitisha udhibiti wa hostname moja tu, ambayo validation server ilitumia kufetch file hiyo. Wildcard ni dai kuhusu kila jina linalowezekana chini ya domain, na record pekee ya umma inayowakilisha namespace nzima ni DNS yenyewe.

Sharti hilo moja huamua kila jambo lingine kwenye ukurasa huu. Ili kupitisha DNS-01, lazima uweze kuunda TXT records katika zone ya domain, wewe mwenyewe au kupitia API (application programming interface) ya DNS provider wako. Njia ya kuunda records wewe mwenyewe hufanya kazi mara moja, kisha hushindwa wakati wa renewal kwa sababu maalumu iliyoonyeshwa hapa chini. Njia ya API, kupitia Certbot DNS plugin, hufanya renewal bila uangalizi, na ndiyo usanidi unaopaswa kutumia mwishoni.

Hii ni sura ya wildcard katika mwongozo wetu wa Certbot. Single-hostname certificates za kawaida, usanidi wa web server na rules za port 80 zimeelezwa 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 provider wako haipo kwenye apt

Archive ya 24.04 huweka vifurushi vya plugins za providers wachache tu, wakiwemo Cloudflare, Route 53, DigitalOcean na interface ya jumla ya RFC 2136. Endesha apt search certbot-dns ili kuona orodha. Ikiwa provider wako hayupo, hapa ndipo ushauri wetu wa kuanza na apt unapobadilika: sakinisha Certbot na plugin kutoka snap badala yake, na kwanza ondoa Certbot ya apt ili timers mbili za renewal 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 huunganisha tu na Certbot ya snap; haiwezi kuipanua Certbot ya apt. Ndiyo sababu installations hizi mbili hazipaswi kuwepo pamoja. Ikiwa host wako wa DNS hana API kabisa, chaguo zako halisi ni kuhamisha DNS ya domain kwenda kwa provider mwenye API, au kuendesha name server yako mwenyewe na kuelekeza plugin ya rfc2136 kwake.

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 certificate ya wildcard kwa kutumia HTTP-01?

Hapana. HTTP-01 huthibitisha udhibiti wa hostname moja, kwa sababu seva ya uthibitishaji huchota faili la tokeni kutoka kwenye jina hilo mahususi. Wildcard inajumuisha kila jina lililo chini ya domain, hivyo Let's Encrypt huhitaji challenge ya DNS-01 kwa ajili yake, na authenticators za --nginx, --apache, --webroot na --standalone zote hutumia HTTP. Njia pekee ni kuweka TXT record kwenye _acme-challenge.example.com, ama wewe mwenyewe au kupitia DNS plugin.

Je, certificate ya wildcard inajumuisha root domain?

Hapana. Wildcard hulingana na label moja pekee, hivyo *.example.com inajumuisha www.example.com lakini si example.com isiyo na subdomain, wala a.b.example.com. Omba majina yote mawili kwenye certificate moja kwa kutumia -d example.com -d '*.example.com'. Hii huunda challenges mbili, na TXT records zote mbili huwekwa kwenye jina lilelile la _acme-challenge.example.com. Kwa hiyo, ongeza record ya pili bila kufuta ya kwanza.

Kwa nini certificate yangu ya wildcard haisasishwi kiotomatiki?

Kwa sababu ilitolewa kwa kutumia --manual. Kila renewal huhitaji thamani mpya kabisa ya TXT, na timer inayojiendesha bila uangalizi haina njia ya kuiweka. Kwa hiyo, renewal husimama na error ya An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively. Toa tena certificate kwa DNS plugin kama certbot-dns-cloudflare, au toa scripts za --manual-auth-hook na --manual-cleanup-hook zinazohariri record kupitia API ya mtoa huduma wako.

Inachukua muda gani _acme-challenge TXT record kuonekana?

Inategemea mtoa huduma wako wa DNS: inaweza kuchukua kuanzia sekunde chache hadi dakika kadhaa. Uthibitishaji husoma authoritative servers za zone yako. Kwa hiyo, kagua kwa dig +short TXT _acme-challenge.example.com @1.1.1.1 na usubiri hadi thamani inayotarajiwa ionekane kabla ya kuendelea na run ya mwongozo. Unapotumia plugin, ongeza muda wa kusubiri uliojengewa ndani kupitia propagation option ya plugin, kwa mfano --dns-cloudflare-propagation-seconds 60, ikiwa uthibitishaji utaripoti kuwa record haikupatikana.

Je, certificate ya wildcard si salama kuliko certificate ya kawaida?

Cryptography ni ileile. Tofauti ziko kwenye uendeshaji: private key moja inatumika kwa kila subdomain, hivyo server ikibreached athari huenea zaidi. Pia, DNS API credential inayohitajika kwa automation ni secret nyeti inayohifadhiwa kwenye seva. Ikiwa unaendesha subdomain chache zinazojulikana, SAN certificate huepuka matatizo yote mawili. Hiyo ndiyo hali ambayo mwongozo huu unapendekeza usitumie wildcard.