SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-01

Certbotలో Wildcard సర్టిఫికేట్‌కు DNS-01 సెటప్

Certbotతో DNS-01 challenge ఉపయోగించి wildcard certificate జారీ చేయడం నేర్చుకోండి. TXT record proof, అవసరమైన DNS plugin, renewal ఆటోమేటిక్‌గా ఎలా జరుగుతుందో చూడండి.

వైల్డ్‌కార్డ్ సర్టిఫికేట్‌కు DNS-01 ఎందుకు అవసరం

వైల్డ్‌కార్డ్ సర్టిఫికేట్ ఒక డొమైన్‌లోని ప్రతి మొదటి-స్థాయి సబ్‌డొమైన్‌ను కవర్ చేస్తుంది: *.example.com, app.example.com, blog.example.com మరియు లేబుల్ లోతు ఒకటిగా ఉన్న ఇతర పేర్లన్నింటినీ *.example.com సరిపోల్చుతుంది. Let's Encrypt వైల్డ్‌కార్డ్ సర్టిఫికేట్‌లను DNS-01 challenge ద్వారా మాత్రమే జారీ చేస్తుంది. అందువల్ల Certbot, _acme-challenge.example.com వద్ద TXT record ప్రచురించడం ద్వారా డొమైన్ DNS నియంత్రణ మీ వద్ద ఉందని నిరూపించాలి. HTTP-01 challenge దీనికి సరిపోదు. ఎందుకంటే validation server ఏ hostname నుంచి token fileను పొందుతుందో, ఆ ఒక్క hostnameపై నియంత్రణ ఉందని మాత్రమే fileను అందించడం నిరూపిస్తుంది. వైల్డ్‌కార్డ్ అనేది డొమైన్‌లోని ప్రతి సాధ్యమైన పేరుపై హక్కును సూచిస్తుంది. మొత్తం namespace తరఫున మాట్లాడే ఏకైక public record DNS.

ఈ ఒక్క అవసరమే ఈ పేజీలోని మిగతా విధానాన్ని నిర్ణయిస్తుంది. DNS-01ను విజయవంతంగా పూర్తి చేయడానికి, మీరు డొమైన్ zoneలో TXT recordsను చేతితో లేదా మీ DNS provider యొక్క API (application programming interface) ద్వారా సృష్టించగలగాలి. చేతితో చేసే విధానం ఒకసారి పనిచేస్తుంది. కానీ renewal సమయంలో అది విఫలమవుతుంది. దానికి స్పష్టమైన కారణం దిగువ చూపబడింది. Certbot DNS plugin ద్వారా API విధానం unattendedగా renewal చేస్తుంది. చివరికి మీరు ఉపయోగించాల్సిన setup ఇదే.

ఇది మా Certbot guidesలోని వైల్డ్‌కార్డ్ అధ్యాయం. సాధారణ single-hostname certificates, web server configuration మరియు port 80 rules గురించి Ubuntu 24.04లో nginxతో Certbot మరియు Ubuntu 24.04లో Apacheతో Certbotలో వివరించాం.

_acme-challenge TXT రికార్డ్ ఎలా పనిచేస్తుంది

Certbot *.example.com కోసం అభ్యర్థించినప్పుడు, Let's Encrypt యాదృచ్ఛిక టోకెన్‌తో సమాధానం ఇస్తుంది. Certbot ఆ టోకెన్‌ను మీ ACME (automatic certificate management environment) ఖాతా కీతో కలిపి, ఫలితానికి SHA-256 హాష్‌ను లెక్కించి, చిన్న టెక్స్ట్ విలువను రూపొందిస్తుంది. ఆ విలువ _acme-challenge.example.com వద్ద TXT రికార్డ్‌గా ఉండాలి. తర్వాత Let's Encrypt తన స్వంత మౌలిక వసతుల నుంచి మీ డొమైన్‌కు సంబంధించిన అధికారిక name servers‌ను ప్రశ్నిస్తుంది. అది చదివిన రికార్డ్, అది ఆశించే విలువతో సరిపోతే, మీరు ఆ zone‌పై నియంత్రణ ఉందని నిరూపించినట్లే. ఆ zone‌పై నియంత్రణను, దాని కింద ఉన్న ప్రతి name‌పై నియంత్రణగా అంగీకరిస్తారు.

చాలా వైఫల్యాలకు ఈ రెండు వివరాలే కారణం:

  • ఒకే సర్టిఫికేట్‌లో example.com మరియు *.example.com కోసం అభ్యర్థించడం అంటే రెండు వేర్వేరు challenges. రెండు TXT రికార్డులు ఒకే name, _acme-challenge.example.com వద్ద ఉంటాయి. రెండూ ఒకేసారి ఉండాలి. రెండో రికార్డును జోడించడం సరైనది; మొదటి రికార్డును రెండో దానితో భర్తీ చేస్తే మొదటి challenge విఫలమవుతుంది.
  • Validation మీ అధికారిక servers‌ను చదువుతుంది. అయితే provider control panels కొత్త రికార్డును వాటికి పంపడానికి ఒక నిమిషం లేదా అంతకంటే ఎక్కువ సమయం తీసుకోవచ్చు. Validation అమలు చేయడానికి ముందు బయట నుంచి తనిఖీ చేయండి:
dig +short TXT _acme-challenge.example.com @1.1.1.1

అది Certbot కోరిన విలువను చూపిస్తే, validation విజయవంతం కావచ్చు. అది ఏమీ చూపించకపోతే, వేచి ఉండి మళ్లీ అమలు చేయండి.

ఇది ఒక్కసారి పనిచేయడాన్ని చూడండి: మాన్యువల్ మోడ్

మాన్యువల్ మోడ్‌లో DNS సవరణను మీరే చేయాలి. ఆటోమేషన్‌కు ముందు విధానం ఎలా పనిచేస్తుందో అర్థం చేసుకోవడానికి ఇది ఉత్తమ మార్గం:

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

Wildcard చుట్టూ ఉన్న quotes, * ను filename patternగా shell పరిగణించకుండా ఆపుతాయి. Certbot సూచనలతో ఆగుతుంది:

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

మీ DNS provider panelలో ఆ TXT recordను సృష్టించండి. పై ఉన్న dig commandతో అది కనిపిస్తోందని నిర్ధారించండి. ఆ తర్వాత మాత్రమే Enter నొక్కండి. ఈ runలో bare domain మరియు wildcard రెండింటినీ అడుగుతున్నందున Certbot రెండుసార్లు prompt చూపిస్తుంది. Issuance పూర్తయ్యే వరకు రెండు recordsను అలాగే ఉంచండి. విజయవంతమైనప్పుడు సాధారణంగా కనిపించే linesతో ప్రక్రియ ముగుస్తుంది:

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

మాన్యువల్ మోడ్ తనంతట తానే ఎందుకు పునరుద్ధరించుకోలదు

ప్రతి పునరుద్ధరణలో కొత్త tokenతో కొత్త challenge ఉంటుంది. అందువల్ల TXT విలువ ప్రతిసారీ మారుతుంది. మీరు ఈరోజు జోడించిన record 60 రోజుల్లో ఉపయోగం లేకుండా పోతుంది. Renewal timer రోజుకు రెండుసార్లు Certbotను unattendedగా అమలు చేస్తుంది. కొత్త విలువను paste చేయడానికి keyboard వద్ద ఎవరూ ఉండరు. అందువల్ల మాన్యువల్‌గా జారీ చేసిన certificate పునరుద్ధరణలో ఈ ఖచ్చితమైన errorతో విఫలమవుతుంది:

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.')

మీ DNS provider యొక్క APIని పిలిచే --manual-auth-hook scripts రాయడం ద్వారా ఈ అవసరాన్ని తీర్చవచ్చు. అయితే ఆ దశలో మీరు DNS pluginను చేతితో మళ్లీ నిర్మిస్తున్నట్లే అవుతుంది. ప్రక్రియను నేర్చుకోవడానికి లేదా ఇంకా DNSను automate చేయలేని domainపై నిజమైన ఒకసారి-మాత్రమే పని కోసం manual modeను ఉపయోగించండి. day 90కు చాలాముందే reminder సెట్ చేయండి, ఎందుకంటే Let's Encrypt ఇకపై expiry emails పంపదు. మిగతా అన్ని సందర్భాల్లో pluginను ఉపయోగించండి.

plugin మార్గం: Ubuntu 24.04లో certbot-dns-cloudflare

DNS plugin మీ DNS provider కోసం API credentialను నిల్వ చేసి, certificate జారీ సమయంలో మరియు ప్రతి renewal సమయంలో TXT record ప్రక్రియను పూర్తిగా నిర్వహిస్తుంది. ఇక్కడ Cloudflareను ఉదాహరణగా ఉపయోగిస్తున్నాం, ఎందుకంటే ఎక్కువ మంది ఉపయోగించే provider plugin ఇదే మరియు ఇది Ubuntuలో packageగా అందుబాటులో ఉంది.

మా Certbot guides Ubuntu 24.04లో apt packagesను సిఫారసు చేస్తాయి. Cloudflare విషయంలో కూడా ఇదే విధానం వర్తిస్తుంది:

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

Versions గురించి ఒక స్పష్టమైన విషయం. 24.04 archiveలో ఈ plugin version 2.0.0గా, Certbot 2.9.0 పక్కన అందుబాటులో ఉంటుంది; apt policy python3-certbot-dns-cloudflare మీ versionను చూపిస్తుంది. ఈ version తేడా సమస్య కాదు. Scoped API tokens పనిచేస్తాయి, ఎందుకంటే 24.04లోని underlying python3-cloudflare library version 2.11.1. Token support కోసం pluginకు అవసరమైన version 2.3.1 కంటే ఇది ఎక్కువ. పాత Ubuntu releasesలో ఆ library tokensకు చాలా పాతది. అందువల్ల apt plugin Global API Keyను తప్పనిసరి చేస్తుందని onlineలో కనిపించే warnings వచ్చాయి. Ubuntu 24.04లో అవి ఇక వర్తించవు.

Cloudflare dashboardలో Global API Key కాకుండా scoped API tokenను సృష్టించండి: My Profile, తర్వాత API Tokens, తర్వాత Create Token ఎంచుకోండి. ఒక్క permission Zone / DNS / Edit మాత్రమే ఇవ్వండి. మీరు certificate జారీ చేస్తున్న ఒక్క zoneకే tokenను పరిమితం చేయండి. ఆ tokenను root మాత్రమే చదవగలిగే fileలో ఉంచండి:

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

Fileను ఇతరులు చదవగలిగితే Certbot modeను తనిఖీ చేసి Unsafe permissions on credentials configuration file గురించి warning ఇస్తుంది. ఇప్పుడు certificateను జారీ చేయండి:

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

Plugin API ద్వారా TXT recordsను సృష్టిస్తుంది. కొద్దిసేపు propagation కోసం వేచి ఉంటుంది. Validation పూర్తయ్యేలా చేస్తుంది. తర్వాత ఆ recordsను మళ్లీ తొలగిస్తుంది. మీ zone name servers మార్పులను స్వీకరించడానికి ఆలస్యం చేస్తే, --dns-cloudflare-propagation-seconds 60తో వేచి ఉండే సమయాన్ని పెంచండి. Certificate /etc/letsencrypt/live/example.com/లో ఉంచబడుతుంది. Base guidesలో చూపిన విధంగానే nginx లేదా Apacheను fullchain.pem మరియు privkey.pemకు point చేయండి. Deploy hookను కూడా చేర్చండి.

మీ provider యొక్క plugin aptలో లేకపోతే

24.04 archiveలో కొద్దిమంది providers కోసం మాత్రమే plugins ప్యాకేజీ చేయబడ్డాయి. వాటిలో Cloudflare, Route 53, DigitalOcean మరియు సాధారణ RFC 2136 interface ఉన్నాయి. జాబితాను చూడటానికి apt search certbot-dns అమలు చేయండి. మీ provider కనిపించకపోతే, ఇక్కడ మాత్రమే మా apt-first సూచనకు మినహాయింపు ఉంటుంది: బదులుగా Certbot మరియు pluginను snap నుంచి install చేయండి. ముందు apt Certbotను remove చేయండి. అప్పుడు రెండు renewal timers /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

snap plugin, snap Certbotకు మాత్రమే connect అవుతుంది. అది apt Certbotను extend చేయలేదు. అందుకే ఈ రెండు installations ఒకేసారి ఉండకూడదు. మీ DNS hostలో API అసలు లేకపోతే, మీకు వాస్తవికంగా రెండు ఎంపికలు ఉన్నాయి: DNS ఉన్న providerకు domain యొక్క DNSను తరలించడం, లేదా మీ స్వంత name serverను అమలు చేసి rfc2136 pluginను దానికి point చేయడం.

పునరుద్ధరణ: 60 రోజుల తర్వాత కాకుండా ఇప్పుడే నిరూపించండి

Certbot ప్రతి సర్టిఫికేట్ ఎలా జారీ చేయబడిందో /etc/letsencrypt/renewal/example.com.conf లో నమోదు చేస్తుంది. ఇందులో authenticator = dns-cloudflare మరియు ఆధారాల పాత్ కూడా ఉంటాయి. అందువల్ల, రోజుకు రెండుసార్లు నడిచే ప్రామాణిక timer మీ సహాయం లేకుండానే దాన్ని పునరుద్ధరిస్తుంది. Staging environment కు వ్యతిరేకంగా మొత్తం ప్రక్రియను పరీక్షించండి:

sudo certbot renew --dry-run

పరీక్ష విజయవంతమైతే, ఆధారం పనిచేస్తోందని మరియు validation ప్రారంభం నుంచి ముగింపు వరకు పూర్తవుతోందని అర్థం. 60 రోజుల తర్వాత జరిగే వాస్తవ పునరుద్ధరణ కూడా ఇదే మార్గాన్ని అనుసరిస్తుంది. ఈరోజే రెండు తదుపరి చర్యలు తీసుకోవాలి. మొదటిది, డిస్క్‌లో కొత్తగా పునరుద్ధరించిన సర్టిఫికేట్ ఉన్నా web server దాన్ని reload చేసే వరకు ఎలాంటి మార్పు కనిపించదు. కాబట్టి nginx మరియు Apache guides లో వివరించిన deploy hook ను అనుసంధానించండి. రెండవది, credentials file ను జాగ్రత్తగా భద్రపరచండి. దాన్ని చదవగల ఎవరైనా మీ DNS zone ను సవరించగలరు. దాంతో మీ mail ను దారి మళ్లించవచ్చు లేదా వారి స్వంత DNS-01 challenges ను పూర్తి చేయవచ్చు. దాన్ని /root కింద mode 600 తో ఉంచండి. token పరిధిని ఒక zone కు మాత్రమే పరిమితం చేయండి. ఎప్పుడైనా credential లీక్ అయిందని అనుమానం వస్తే దాన్ని మార్చండి.

వైల్డ్‌కార్డ్ అవసరం లేని సందర్భాలు

అనేక subdomainల కోసం లేదా ముందుగా అంచనా వేయలేని subdomainల కోసం wildcard సరైన సాధనం. మిగతా అన్ని సందర్భాల్లో దీన్ని డిఫాల్ట్‌గా ఉపయోగించడం సరైనది కాదు.

  • ఒక subdomain లేదా ముందుగా తెలిసిన కొన్ని subdomainలు మాత్రమే ఉంటే: సాధారణ SAN (subject alternative name) certificate మరింత సరళంగా ఉంటుంది. certbot --nginx -d example.com -d www.example.com -d app.example.com plain HTTP-01 ద్వారా గరిష్ఠంగా 100 పేర్లను కవర్ చేస్తుంది. అలాగే DNS API credential serverలో ఎప్పుడూ ఉండదు.
  • wildcard సరిగ్గా ఒక labelను మాత్రమే సరిపోలుస్తుంది. *.example.com bare example.comను కవర్ చేయదు. అందుకే పై commands రెండింటినీ అభ్యర్థిస్తాయి. ఇది a.b.example.comను కూడా కవర్ చేయదు; దానికి *.b.example.com అవసరం.
  • ప్రతి subdomain వెనుక ఒకే private key ఉంటుంది. ఆ keyను కలిగి ఉన్న machine breach అయితే, wildcard కవర్ చేసే ప్రతి పేరు ఒకేసారి ప్రభావితమవుతుంది.
  • Traefik మీ containers కోసం TLS (transport layer security)ను terminate చేస్తే, Certbotను ఉపయోగించాల్సిన అవసరం లేదు: Traefik స్వయంగా DNS-01 ద్వారా wildcard certificatesను అభ్యర్థిస్తుంది. ఇందుకు అదే రకమైన provider tokenను ఉపయోగిస్తుంది.

మీకు wildcard నిజంగా ఉపయోగపడే సందర్భాలు: మీరు certificatesను మళ్లీ issue చేయాలనుకునే వేగం కంటే వేగంగా సృష్టించే customer లేదా app subdomainలు, అలాగే public port 80 లేని internal hosts. ఉదాహరణకు, WireGuard VPN ద్వారా మాత్రమే చేరుకోగల services. DNS-01 certificate పొందుతున్న hostకు ఎప్పుడూ connection ఏర్పాటు చేయదు. అందువల్ల పూర్తిగా private machine కూడా public trust ఉన్న certificateను కలిగి ఉండవచ్చు.

FAQ

Certbot HTTP-01తో wildcard సర్టిఫికేట్ జారీ చేయగలదా?

లేదు. HTTP-01 ఒక hostname నియంత్రణను మాత్రమే నిరూపిస్తుంది, ఎందుకంటే validation server ఆ hostname నుంచే token fileను పొందుతుంది. wildcard domain కింద ఉన్న ప్రతి hostnameను కవర్ చేస్తుంది. అందువల్ల Let's Encrypt దానికి DNS-01 challengeను అవసరం చేస్తుంది. అయితే --nginx, --apache, --webroot మరియు --standalone authenticators అన్నీ HTTP ఆధారితమైనవి. అందుబాటులో ఉన్న ఏకైక మార్గం _acme-challenge.example.com వద్ద TXT recordను ఉంచడం. దీన్ని మాన్యువల్‌గా లేదా DNS plugin ద్వారా సృష్టించవచ్చు.

wildcard సర్టిఫికేట్ root domainను కవర్ చేస్తుందా?

లేదు. wildcard ఖచ్చితంగా ఒక labelను మాత్రమే సరిపోలుస్తుంది. అందువల్ల *.example.com, www.example.comను కవర్ చేస్తుంది. కానీ bare example.comను లేదా a.b.example.comను కవర్ చేయదు. -d example.com -d '*.example.com'తో రెండు పేర్లను ఒకే సర్టిఫికేట్‌లో అభ్యర్థించండి. ఇది రెండు challengesను సృష్టిస్తుంది. రెండు TXT records ఒకే _acme-challenge.example.com పేరులో ఉంటాయి. కాబట్టి మొదటి recordను తొలగించకుండా రెండవ recordను జోడించండి.

నా wildcard సర్టిఫికేట్ స్వయంచాలకంగా ఎందుకు renew కావడం లేదు?

దీనికి కారణం అది --manualతో జారీ చేయబడింది. ప్రతి renewalకు పూర్తిగా కొత్త TXT value అవసరం. Unattended timerకు ఆ విలువను నమోదు చేసే మార్గం లేదు. అందువల్ల renewal An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively లోపంతో ఆగిపోతుంది. certbot-dns-cloudflare వంటి DNS pluginతో సర్టిఫికేట్‌ను మళ్లీ జారీ చేయండి. లేదా మీ provider API ద్వారా recordను సవరించే --manual-auth-hook మరియు --manual-cleanup-hook scriptsను అందించండి.

_acme-challenge TXT record కనిపించడానికి ఎంత సమయం పడుతుంది?

ఇది మీ DNS providerపై ఆధారపడి ఉంటుంది. కొన్ని సెకన్ల నుంచి కొన్ని నిమిషాల వరకు పట్టవచ్చు. Validation మీ zone యొక్క authoritative serversను చదువుతుంది. కాబట్టి dig +short TXT _acme-challenge.example.com @1.1.1.1తో తనిఖీ చేయండి. మాన్యువల్ runను కొనసాగించే ముందు ఆశించిన value కనిపించే వరకు వేచి ఉండండి. Pluginను ఉపయోగిస్తే, validation record కనబడలేదని నివేదించినప్పుడు plugin యొక్క propagation option ద్వారా అంతర్గత నిరీక్షణ సమయాన్ని పెంచండి. ఉదాహరణకు --dns-cloudflare-propagation-seconds 60ను ఉపయోగించవచ్చు.

సాధారణ సర్టిఫికేట్ కంటే wildcard సర్టిఫికేట్ తక్కువ సురక్షితమా?

క్రిప్టోగ్రఫీ ఒకటే. తేడాలు నిర్వహణకు సంబంధించినవి. ఒక private key ప్రతి subdomainను కవర్ చేస్తుంది. కాబట్టి server breach అయితే దాని ప్రభావం మరింత విస్తరిస్తుంది. అదనంగా, automationకు అవసరమైన DNS API credential serverలో నిల్వ చేయబడే సున్నితమైన secret. మీరు కొన్ని తెలిసిన subdomains మాత్రమే నడుపుతున్నట్లయితే, SAN certificate ఈ రెండు సమస్యలను నివారిస్తుంది. అందుకే wildcardను ఉపయోగించకుండా ఉండాలని ఈ guide సిఫారసు చేస్తుంది.