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

Ubuntu 24.04 nginx కోసం Certbot ఇన్‌స్టాల్

sudo apt install certbot python3-certbot-nginx తర్వాత certbot --nginx నడిపి Let's Encrypt సర్టిఫికెట్ పొందండి. apt vs snap తేడాలు, పోర్ట్ 80 రిన్యూవల్ టైమౌట్ సహా వివరాలు ఇందులో.

Certbot నిర్మాణం: apt లేదా snap

Ubuntu 24.04లో, sudo apt install certbot python3-certbot-nginx మీకు సరైన Certbotను ఇస్తుంది. అది వాస్తవ, ప్రజాప్రతిష్ట కలిగిన Let's Encrypt ధృవీకరణపత్రాలను జారీ చేస్తుంది. Certbot అధికారిక పత్రాలు మిమ్మల్ని snap వైపు నిర్దేశిస్తాయి. తేడా చాలా తక్కువ. snap అప్‌స్ట్రీమ్ విడుదలలను అనుసరిస్తుంది. ఆర్కైవ్ ప్యాకేజీ LTSతో పంపిణీ చేయబడిన వెర్షన్‌ను అనుసరిస్తుంది. దానికి భద్రతా పరిష్కారాలు వస్తాయి.

ఒకటి ఎంచుకోండి. Certbot యొక్క రెండు కాపీలు ఉండటం అంటే ఒకే /etc/letsencrypt వృక్షం వైపు రెండు పునరుద్ధరణ టైమర్‌లు పనిచేస్తాయి. మీరు మర్చిపోయినది మిమ్మల్ని ఆశ్చర్యపరుస్తుంది.

apt మార్గం:

sudo apt update
sudo apt install certbot python3-certbot-nginx

అది /usr/bin/certbot, nginx ప్లగిన్, ఒక certbot.service + certbot.timer జంట మరియు systemd కింద నో-ఆప్ అయ్యే ఒక /etc/cron.d/certbot ఎంట్రీని నిర్మాణిస్తుంది.

snap మార్గం:

sudo apt remove certbot python3-certbot-nginx
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

snap దాని స్వంత టైమర్ snap.certbot.renew.timerను కలిగి ఉంటుంది. snap నిర్మాణించడానికి ముందు apt ప్యాకేజీని తొలగించండి.

తరువాత రెండు నిర్మాణాలు ఒకేలా ప్రవర్తిస్తాయి. Certbot 2.x అప్రమేయంగా ECDSA (P-256) కీలను ఉపయోగిస్తుంది. ECDSA చేయలేని క్లయింట్ కోసం మాత్రమే --key-type rsa పాస్ చేయండి. అన్ని స్థితి /etc/letsencrypt కింద ఉంటుంది: archive/ నిజమైన కీ మరియు ధృవీకరణపత్ర ఫైళ్లను కలిగి ఉంటుంది, live/ ప్రస్తుత ఫైళ్లకు సింలింక్‌లను కలిగి ఉంటుంది, renewal/ ఒక్కో ధృవీకరణపత్రానికి ఒక కాన్ఫిగ్ ఫైల్‌ను కలిగి ఉంటుంది, accounts/ మీ ACME ఖాతా కీని కలిగి ఉంటుంది.

HTTP-01 వాస్తవానికి ఏమి చేస్తుంది, మరియు పోర్ట్ 80 ఐచ్ఛికం కాదు ఎందుకంటే

HTTP-01 సవాలు ఒక కాల్‌బ్యాక్. మీరు Let's Encrypt నుండి example.com కవర్ చేసే సర్టిఫికేట్‌ను అభ్యర్థిస్తారు. అది పబ్లిక్ DNSలో పేరును పరిష్కరిస్తుంది, అది కనుగొన్న చిరునామా వద్ద పోర్ట్ 80కి కనెక్షన్‌ను తెరుస్తుంది, మరియు http://example.com/.well-known/acme-challenge/<token> అభ్యర్థిస్తుంది. మీ సర్వర్ Certbot ఇప్పుడే డిస్క్‌కు వ్రాసిన సరైన టోకెన్ కంటెంట్‌తో స్పందిస్తుంది. ఇదంతా యంత్రాంగం. దీని వల్ల మూడు పర్యవసానాలు వస్తాయి, అవి చాలా విఫల జారీలకు కారణమవుతాయి.

  • పోర్ట్ 80 పబ్లిక్ ఇంటర్నెట్ నుండి చేరుకోగలిగేలా ఉండాలి, కేవలం మీ ల్యాప్‌టాప్ నుండి కాదు. ufw నియమం, క్లౌడ్-ప్రొవైడర్ సెక్యూరిటీ గ్రూప్, లేదా 443 మాత్రమే తెరిచే VPS-కన్సోల్ ఫైర్‌వాల్ జారీని మరియు ప్రతి భవిష్యత్ రెన్యూవల్‌ను విచ్ఛిన్నం చేస్తుంది.
  • DNS ఇప్పటికే ఈ బాక్స్‌ను సూచించాలి. వాలిడేషన్ సర్వర్ బయటి నుండి దాని స్వంత లుకప్‌ను చేస్తుంది; మీ /etc/hosts ఎంట్రీలు మరియు బ్రౌజర్ కాష్ దానికి అర్థం కావు.
  • మీరు AAAA రికార్డ్‌ను ప్రచురిస్తే, IPv6 ముందుగా ప్రయత్నించబడుతుంది. IPv6 కనెక్షన్ పూర్తిగా విఫలమైనప్పుడు Let's Encrypt IPv4 ద్వారా మళ్లీ ప్రయత్నిస్తుంది — కానీ కనెక్షన్‌ను అంగీకరించి మరేదైనా సర్వ్ చేసే హోస్ట్‌ను సూచించే పాత AAAA మీకు ఖచ్చితమైన వైఫల్యాన్ని ఇస్తుంది.

రీడైరెక్ట్‌లు అనుమతించబడతాయి: వాలిడేషన్ HTTP రీడైరెక్ట్‌ను HTTPSకి అనుసరిస్తుంది మరియు మరొక చివరలో ఉన్న సర్టిఫికేట్ లేకపోవడం, గడువు ముగియడం లేదా సెల్ఫ్-సైన్డ్ అవడం పట్టిక లేదు. అది చేయని పని ఏమిటంటే, పోర్ట్ 80 కాకుండా మరే ఇతర ప్రదేశం నుండి ప్రారంభించడం. Certbotలో TLS-ALPN-01 అమలు లేదు, కాబట్టి "కేవలం 443 ఉపయోగించండి" అనేది ఎస్కేప్ హాచ్ కాదు.

ఆథెంటికేటర్‌ను ఎంచుకోవడం: --nginx, --webroot, --standalone

--nginx అనేది nginx ఇప్పటికే నడుస్తూ, ఆ డొమైన్‌కు సేవలందిస్తున్నప్పుడు సరైన డిఫాల్ట్. Certbot మీ కాన్ఫిగరేషన్‌ను పార్స్ చేస్తుంది, తాత్కాలిక ఛాలెంజ్ లొకేషన్‌ను చేరుస్తుంది, nginxను రీలోడ్ చేస్తుంది, ధృవీకరిస్తుంది, తర్వాత TLS డైరెక్టివ్‌లను మీ సర్వర్ బ్లాక్‌లోకి వ్రాస్తుంది. ఎలాంటి డౌన్‌టైమ్ ఉండదు.

sudo certbot --nginx -d example.com -d www.example.com

కొత్త సర్వర్ కోసం స్క్రిప్టెడ్ విధానం:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --agree-tos -m ops@example.com --no-eff-email \
  --redirect --non-interactive

--webroot మీరు Certbotను మీ nginx కాన్ఫిగరేషన్ దగ్గరకు రానివ్వాలనుకోనప్పుడు సరైనది — ఆ కాన్ఫిగరేషన్‌ను మీరు టెంప్లేట్ నుండి తయారుచేస్తారు, git‌లో ఉంచుతారు, లేదా Ansibleతో పుష్ చేస్తారు. Certbot ఛాలెంజ్ ఫైల్‌ను మాత్రమే, మీరు ఇప్పటికే సేవలందిస్తున్న డైరెక్టరీలోకి వ్రాస్తుంది.

sudo certbot certonly --webroot -w /var/www/example.com \
  -d example.com -d www.example.com \
  --deploy-hook "systemctl reload nginx"

--standalone పోర్ట్ 80లో ఏదీ లిజన్ చేయనప్పుడు సరైనది: ఒక మెయిల్ సర్వర్, 443 మాత్రమే మాట్లాడే ఒక API, nginx ఉనికిలోకి రాకముందే నడిచే ఫస్ట్-బూట్ స్క్రిప్ట్. Certbot పోర్ట్ 80ను కొన్ని సెకన్ల పాటు తానే బైండ్ చేస్తుంది. nginx నడుస్తూనే ఉంటే, ఇది విఫలమవుతుంది — రన్ సమయంలో దాన్ని ఆపండి:

sudo certbot certonly --standalone -d mail.example.com \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

ఆ హుక్‌లు సర్టిఫికేట్ రిన్యూవల్ కాన్ఫిగరేషన్‌లో నమోదవుతాయి, కాబట్టి రిన్యూవల్ సమయంలో అదే స్టాప్/స్టార్ట్ ఎటువంటి పర్యవేక్షణ లేకుండా జరుగుతుంది.

ధృవీకరణపత్రం ఉనికిలో ఉన్నప్పుడు, లేనప్పుడు పనిచేసే సర్వర్ బ్లాక్

ముందస్తు సమస్య: nginx ప్రారంభం కావడం విఫలమవుతుంది, ఎందుకంటే ssl_certificate ఉనికిలో లేని ఫైల్‌ను సూచిస్తోంది. nginx ఆగిపోయినప్పుడు Certbot ధృవీకరణ చేయలేకపోతుంది. ముందుగా పోర్ట్ 80 పై సైట్‌ను ప్రారంభించండి.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo nginx -t && sudo systemctl reload nginx ని అమలు చేయండి. సర్వర్ బయట నుండి curl -I http://example.com/ స్పందిస్తుందని నిర్ధారించుకోండి. తర్వాత జారీ చేయండి. తదుపరి చర్యలు:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

ACME లొకేషన్‌పై ^~ ప్రిఫిక్స్ ఉపయోగకరంగా ఉంటుంది: ఇది return 301 బ్లాక్ ఛాలెంజ్ అభ్యర్థనను గ్రహించకుండా నిరోధిస్తుంది. ఆ లొకేషన్‌ను పోర్ట్ 80 పై ఉంచడం అంటే, సైట్‌లోని మిగిలిన భాగం HTTPS మాత్రమే అయిన తర్వాత కూడా రెన్యూవల్‌లు కొనసాగుతాయి.

HTTP/2 సింటాక్స్ మీ nginx వెర్షన్‌పై ఆధారపడి ఉంటుంది. రెండు రూపాలను కలపడం వల్ల ప్రారంభ దోషం వస్తుంది. Ubuntu 24.04 లో nginx 1.24 ఉంటుంది, అది దాన్ని ఇన్‌లైన్‌గా కావాలి — listen 443 ssl http2;. Debian 13 లో కొత్త nginx ఉంటుంది, అది ప్రత్యేక http2 on; డైరెక్టివ్‌ను కావాలి. ముందుగా nginx -v తనిఖీ చేయండి.

nginx ను live/ కు సూచించండి, archive/ కు ఎప్పుడూ కాదు. ప్రతి రెన్యూవల్‌పై live/ సిమ్‌లింక్‌లు తిరిగి సూచించబడతాయి; archive/ కు హార్డ్ పాత్ ఉంచడం వల్ల మీరు ఒక నిర్దిష్ట ధృవీకరణపత్రానికి పరిమితం అవుతారు, అది మీ కంటే ముందే గడువు ముగుస్తుంది.

వైల్డ్‌కార్డ్ అంటే DNS-01, మరియు DNS-01 అంటే ఒక ప్లగిన్

వైల్డ్‌కార్డ్ సర్టిఫికేట్‌ను (*.example.com) HTTP-01 ద్వారా ధృవీకరించలేరు — ఒక ఫైల్‌ను పొందడానికి ఒకే హోస్ట్‌నేమ్ లేదు. DNS-01 మాత్రమే మార్గం: మీరు ఒక _acme-challenge.example.com TXT రికార్డ్‌ను ప్రచురించడం ద్వారా నియంత్రణను రుజువు చేస్తారు. దాన్ని ఎవరి పర్యవేక్షణ లేకుండా చేయడానికి మీ DNS ప్రొవైడర్ కోసం Certbot‌కు API ఆధారాలు కావాలి, ప్రొవైడర్ ప్లగిన్‌లు అందుకే ఉన్నాయి. పూర్తి వైల్డ్‌కార్డ్ సర్టిఫికేట్ వాక్‌థ్రూ TXT రికార్డ్ యాంత్రికతను మరియు మాన్యువల్ మోడ్‌లో రెన్యూవల్ ఊబిని వివరిస్తుంది; చిన్న Cloudflare వెర్షన్ కింద ఉంది.

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

దానికి బదులుగా apt మార్గంలో అది sudo apt install python3-certbot-dns-cloudflare. ఆధారాలు కేవలం root చూడగలిగే ఒక ఫైల్‌లో ఉంటాయి:

# /root/.secrets/cloudflare.ini
# then: sudo chmod 600 /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your_scoped_token_here

ఆ టోకెన్‌ను ఆ ఒక్క జోన్‌పై DNS-ఎడిట్ హక్కులకు పరిమితం చేయండి. అది మీ DNSకి ఒక తాళం చెవి; దాన్ని అలాగే భావించండి.

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

మీ షెల్ దాన్ని గ్లాబ్ చేయకుండా ఉండటానికి వైల్డ్‌కార్డ్‌ను కోట్ చేయండి. DNS-01 HTTP-01 పరిష్కరించలేని వాటిని కూడా పరిష్కరిస్తుంది: పబ్లిక్ పోర్ట్ 80 లేని హోస్ట్‌ల కోసం సర్టిఫికేట్‌లు — ఒక అంతర్గత సేవ, ఒక VPSలో సెల్ఫ్-హోస్టెడ్ WireGuard VPN ద్వారా మాత్రమే చేరుకోగలిగే ఒక బాక్స్, ప్రైవేట్ ఇంటర్‌ఫేస్‌లో ఒక అడ్మిన్ ప్యానెల్.

పునరుద్ధరణ: 90 రోజులు, టైమర్, డిప్లాయ్ హక్

Let's Encrypt సర్టిఫికెట్‌లు 90 రోజులు చెల్లుబాటులో ఉంటాయి. 30 రోజుల కన్నా తక్కువ సమయం మిగిలి ఉన్నప్పుడు Certbot పునరుద్ధరిస్తుంది. దీని వలన మీకు 30 రోజుల విండో లభిస్తుంది. ఈ వ్యవధిలో పునరుద్ధరణ విఫలమైతే అది సర్దుకోగలిగే సమస్యే తప్ప ఆగిపోవడం కాదు. Let's Encrypt ఇక గడువు హెచ్చరిక ఇమెయిల్‌లను పంపదు. ఎవరూ మీకు హెచ్చరించరు. కాబట్టి పర్యవేక్షణ ఇప్పుడు మీ బాధ్యత.

మీ ఇన్‌స్టాలేషన్‌తో వచ్చిన టైమర్‌ను తనిఖీ చేయండి:

systemctl list-timers 'certbot*' 'snap.certbot*'
sudo certbot certificates

certbot renew /etc/letsencrypt/renewal/‌లోని ప్రతి కాన్ఫిగరేషన్‌ను పరిశీలిస్తుంది. 30 రోజుల విండో వెలుపల ఉన్న వాటిని వదిలేస్తుంది. మిగిలిన వాటిని మొదటి రన్‌లో వాడిన ఫ్లాగ్‌లతో పునరుద్ధరిస్తుంది. అందుకే మొదటి రన్ ముఖ్యం. అది నమోదు చేయబడుతుంది.

డిస్క్‌లో ఉన్న ఫైల్‌ను పునరుద్ధరించడం మాత్రమే ఏమీ మార్పు తీసుకురాదు. దానికి రీలోడ్ చేయమని చెప్పే వరకు nginx మెమరీలో ఉన్న పాత సర్టిఫికెట్‌నే అందిస్తూ ఉంటుంది. ఒక్కసారి డిప్లాయ్ హక్‌ను అమర్చండి:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
set -e
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

renewal-hooks/deploy/‌లో ఉన్న ఏ ఎగ్జిక్యూటబుల్ అయినా పునరుద్ధరణ విజయవంతం అయిన తర్వాత నడుస్తుంది. ఒక సర్టిఫికెట్‌కు --deploy-hook ఫ్లాగ్ అదే పనిని చేస్తుంది. దాని పునరుద్ధరణ కాన్ఫిగరేషన్‌లో renew_hook = ...‌ను నిల్వ చేస్తుంది. certbot --nginx మీ కోసం రీలోడ్ చేస్తుంది. --webroot మరియు --standalone సెటప్‌లు చేయవు. హక్ లేకపోవడమే ఒక సైట్ గడువు ముగిసిన సర్టిఫికెట్‌ను అందించడానికి కారణం. అదే సమయంలో certbot certificates కొత్త సర్టిఫికెట్ ఉందని నివేదిస్తూ ఉంటుంది. ప్రారంభంలో సర్టిఫికెట్‌ను చదివే మరేదైనా అదే హక్‌ను కావాలి. Docker, TLS మరియు బ్యాకప్‌లతో Nextcloud VPS ఇన్‌స్టాలేషన్ వంటి కంటైనరైజ్డ్ యాప్‌కు కూడా దీనికే రీస్టార్ట్ లేదా రీలోడ్ అమరిక అవసరం.

వాస్తవ రెన్యూవల్ పరీక్ష

sudo certbot renew --dry-run

అది Let's Encrypt యొక్క staging environment వ్యతిరేకంగా పూర్తి ఛాలెంజ్‌ను నడుపుతుంది: అదే కోడ్ పాత్, అదే ఫైర్‌వాల్, అదే DNS, rate-limit వ్యయం లేదు, డిస్క్‌కు ఏమీ రాయబడదు. అది ఈ రోజు పాస్ అయితే, బాక్స్ గురించి దాని కింద ఏమీ మారకపోతే, 60 రోజుల్లో జరిగే unattended renewal కూడా పాస్ అవుతుంది.

డ్రై రన్ మీ reload hook ఫైర్ అవుతుందని రుజువు చేయదు — అక్కడ ప్రవర్తన Certbot వర్షన్‌ను బట్టి మారుతుంది. ఆ సగభాగాన్ని మాన్యువల్‌గా పరీక్షించండి: hook స్క్రిప్ట్‌ను నేరుగా అమలు చేయండి, systemctl reload nginx విజయవంతమవుతుందో నిర్ధారించండి, మరియు sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf తనిఖీ చేయండి.

మీరు నిజంగా ఎదుర్కొనే దోషాలు

Could not bind to IPv4 or IPv6. — nginx ఇప్పటికే పోర్ట్ 80 ను ఉపయోగిస్తున్నప్పుడు --standalone. --nginx లేదా --webroot ఉపయోగించండి, లేదా రన్ సమయంలో nginx ను ఆపండి. sudo ss -lntp | grep ':80' తో ఆ పోర్ట్ ను ఎవరు ఉపయోగిస్తున్నారో నిర్ధారించుకోండి.

Timeout during connect (likely firewall problem) — Let's Encrypt పోర్ట్ 80 ను చేరుకోలేకపోయింది. బయటి నుండి తనిఖీ చేయండి: sudo ufw status (దాన్ని sudo ufw allow 'Nginx Full' తో తెరవండి), తర్వాత VPS ప్రొవైడర్ యొక్క స్వంత ఫైర్‌వాల్, తర్వాత DNS. మీ సర్వర్ కాని ప్రదేశం నుండి పరీక్షించండి: curl -sSv http://example.com/.well-known/acme-challenge/test. పాత AAAA రికార్డ్ కూడా ఇదే సందేశాన్ని ఇస్తుంది.

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404 — పోర్ట్ 80 చేరుకోగలుగుతున్నది, కానీ టోకెన్ సర్వ్ చేయబడడం లేదు. అభ్యర్థన వేరే సర్వర్ బ్లాక్‌లో పడింది (default_server ను ఏ బ్లాక్ నియంత్రిస్తుందో తనిఖీ చేయండి), లేదా -w కు అందించిన డైరెక్టరీ nginx సర్వ్ చేసేది కాదు. /var/www/example.com/.well-known/acme-challenge/test వద్ద ఒక ఫైల్ ఉంచి దాన్ని బయటి నుండి పొందండి; అది 404 ఇస్తే, సర్టిఫికేట్ ఎప్పుడూ సమస్యే కాదు.

DNS problem: NXDOMAIN looking up A for example.com — ఆ పేరు బహిరంగంగా రిజాల్వ్ కావడం లేదు. ప్రచారం కాని కొత్త రికార్డులు, లేదా మీ రిజిస్ట్రార్ సర్వ్ చేయని జోన్‌లోని రికార్డు.

too many certificates already issued for: example.com — ఒక రేట్ లిమిట్, మరియు లూప్‌లో డీబగ్ చేస్తూ ప్రజలు ఎదుర్కొనేది. Let's Encrypt డూప్లికేట్ సర్టిఫికేట్‌లను — అదే సెట్ పేర్లు — వారానికి ఐదు వరకు పరిమితం చేస్తుంది, మరియు ప్రత్యేకంగా నమోదైన ప్రతి డొమైన్‌కు వారానికి 50 కొత్త సర్టిఫికేట్‌లను అనుమతిస్తుంది; సమయం తప్ప వేరే ఏదీ వీటిని అన్‌బ్లాక్ చేయదు. --dry-run తో స్టేజింగ్‌పై డీబగ్ చేయండి.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory — nginx జారీ చేయని సర్టిఫికేట్ కోసం కాన్ఫిగర్ చేయబడింది, లేదా certbot delete తో తొలగించబడినది. TLS సర్వర్ బ్లాక్‌ను కామెంట్ చేయండి, nginx ను ప్రారంభించండి, జారీ చేయండి, ఆపై ఆ బ్లాక్‌ను పునరుద్ధరించండి.

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed — ఆ ఫైల్ nginx ప్లగిన్ ప్యాకేజీతో వస్తుంది. python3-certbot-nginx లేని certonly బాక్స్‌లో, ప్లగిన్‌ను జోడించండి లేదా include లైన్‌ను మీ స్వంత ssl_protocols మరియు ssl_ciphers సెట్టింగులతో భర్తీ చేయండి.

దీన్ని పెద్ద ఎత్తున నిర్వహించడం

ఒక సర్టిఫికేట్ 100 పేర్లను కలిగి ఉండగలదు. ఒకే certbot --nginx -d a.example.com -d b.example.com ... ఉపయోగించాలని అనిపిస్తుంది — ఒక పాత DNS రికార్డు ధృవీకరణ విఫలమై, ఆ సర్టిఫికేట్‌లోని మిగతా ప్రతి పేరును కూడా కిందకు లాగే వరకు. ప్రతి సైట్‌కు విడిగా సర్టిఫికేట్‌లు స్వతంత్రంగా వైఫల్యాన్ని ఎదుర్కొంటాయి. ఒక సర్వర్‌లో రెండు కంటే ఎక్కువ విషయాలు హోస్ట్ చేస్తుంటే ఇదే మీరు కోరుకునేది. కొన్ని సైట్లు దాటిన తర్వాత, ACME-అవగాహన ఉన్న ఫ్రంట్ డోర్ ఉపయోగకరంగా ఉంటుంది: Docker Compose కింద బహుళ యాప్‌లను నడుపుతూ ఒక Traefik రివర్స్ ప్రాక్సీ సర్టిఫికేట్‌లను స్వయంగా అభ్యర్థిస్తుంది, పునరుద్ధరిస్తుంది. దీంతో Certbot పూర్తిగా అక్కడి నుండి తప్పుకుంటుంది.

/etc/letsencrypt మొత్తాన్ని బ్యాకప్ చేయండి — sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt — సిమ్‌లింక్‌లు సహితంగా. ఆ ట్రీలో accounts/, మీ ACME ఖాతా కీ ఉంటుంది. దాన్ని మీరు పూర్తిగా ఒకేలా పునఃసృష్టించలేరు. కొత్త VPSకి మారడం అనేది కేవలం ఇవి మాత్రమే: ఆ ట్రీని -aతో rsync చేయడం, Certbot ఇన్‌స్టాల్ చేయడం, DNSని మళ్లించడం, మరియు మార్పిడికి ముందు certbot renew --dry-runని అమలు చేయడం.

సర్వర్‌ను పునర్నిర్మించడం లేదా కొత్త LTSకి మారడం చేసినప్పుడు, పునరుద్ధరణ టైమర్ మీతో పాటు రాదు. ఏ మైగ్రేషన్, స్నాప్‌షాట్ పునరుద్ధరణ, లేదా డిస్ట్రో అప్‌గ్రేడ్ తర్వాత అయినా, systemctl list-timers 'certbot*' మరియు ఒక --dry-run అమలు చేయండి. దాన్ని వదిలేయడం వల్లే 89 రోజుల తర్వాత, ఉదయం 3 గంటలకు, అందరూ స్వయంగా పునరుద్ధరించుకుంటుందని భావించిన సర్టిఫికేట్‌తో ఒక సైట్ అకస్మాత్తుగా ఆగిపోతుంది.

ఇదంతా మీరు నియంత్రించే ఒక మెషీన్‌ను ఊహించుకుంటుంది, అంటే ప్రజా IP మరియు ప్రపంచానికి పోర్ట్ 80 తెరిచి ఉండే ఒక VPS. పై పద్ధతులు ఏ ఒక్కదానిపై అయినా ఒకేలా ఉంటాయి.

అదే సర్టిఫికేట్ దశలు nginx స్థానంలో Apacheపై వర్తిస్తాయి. పబ్లిక్ సర్టిఫికేట్ ఒక ఎంపిక కానప్పుడు, Ubuntuలో స్వయం-సంతకం చేసిన సర్టిఫికేట్ అంతర్గత సేవలను కవర్ చేస్తుంది.

FAQ

నా సైట్‌లో HTTPS మాత్రమే అందించబడినట్లయితే, పోర్ట్ 80 తెరిచి ఉండాలా?

అవును, HTTP-01 సవాలు కోసం. Let's Encrypt దాని ధృవీకరణ అభ్యర్థనను ఎల్లప్పుడూ పోర్ట్ 80 వద్దే ప్రారంభిస్తుంది. Certbot‌లో TLS-ALPN-01 అమలు లేదు. కాబట్టి 443 మాత్రమే తెరిచే ఫైర్‌వాల్ మొదటి జారీని మరియు దాని తర్వాత ప్రతి స్వయంచాలక పునరుద్ధరణను నిరోధిస్తుంది. పోర్ట్ 80 నుండి HTTPS‌కి రీడైరెక్ట్ చేయడం సరే — ధృవీకరణ దాన్ని అనుసరిస్తుంది. పోర్ట్ 80‌ని పూర్తిగా దాటడానికి ఏకైక మార్గం DNS-01 మరియు ప్రొవైడర్ ప్లగిన్.

apt లేదా snap — Ubuntu 24.04‌లో nginx కోసం నేను ఏ Certbot‌ని ఇన్‌స్టాల్ చేయాలి?

apt ఉపయోగించండి. sudo apt install certbot python3-certbot-nginx అనేది Ubuntu 24.04‌లో Certbot 2.9.0‌ని ఇస్తుంది. ఇది ఈ గైడ్‌లోని ప్రతిదానికీ సరిపోతుంది. unattended-upgrades ద్వారా భద్రతా ప్యాచ్‌లను పొందుతుంది. snapd అవసరం లేదు. మీకు వెంటనే కొత్త రిలీజ్ కావాలంటే లేదా ప్రత్యేకంగా snap వలే పంపిణీ చేయబడిన DNS ప్లగిన్ కావాలంటే మాత్రమే snap ఎంచుకోండి. ఏ విషయంలో అయినా, సరిగ్గా ఒకటి మాత్రమే ఎంచుకోండి: రెండు ఇన్‌స్టాలేషన్‌లు అనేది ఒకే /etc/letsencrypt ట్రీ వైపు సూచించే రెండు పునరుద్ధరణ టైమర్‌లను సూచిస్తుంది, మరియు మర్చిపోయినది మిమ్మల్ని ఇబ్బందికి గురిచేస్తుంది.

Certbot nginx కోసం వైల్డ్‌కార్డ్ సర్టిఫికేట్‌ని జారీ చేయగలదా?

DNS-01 ద్వారా మాత్రమే. *.example.com వంటి వైల్డ్‌కార్డ్‌కు సవాలు ఫైల్‌నఁ పొందడానికి ఒకే ఒక్క హోస్ట్‌పేరు లేదు. కాబట్టి --nginx, --webroot మరియు --standalone అన్నీ వీలుకావు. మీ DNS ప్రొవైడర్ కోసం ప్లగిన్‌నఁ ఇన్‌స్టాల్ చేయండి. రూట్-మాత్రమే యాక్సెస్ ఉన్న క్రెడెన్షియల్స్ ఫైల్‌లో స్కోప్ చేయబడిన API టోకెన్‌నఁ ఉంచండి. షెల్ దాన్ని గ్లోబ్ చేయకుండా ఆపడానికి వైల్డ్‌కార్డ్‌నఁ క్వోట్ చేస్తూ certbot certonly --dns-cloudflare -d example.com -d '*.example.com' నఁ అమలు చేయండి.

పునరుద్ధరణ విజయవంతం అయిన తర్వాత nginx ఇంకా పాత సర్టిఫికేట్‌నఁ ఎందుకు అందిస్తుంది?

nginx సర్టిఫికేట్‌నఁ మెమరీలో ఉంచుతుంది. అది రీలోడ్ అయ్యే వరకు డిస్క్‌లోని కొత్త ఫైల్‌నఁ గుర్తించదు. certbot --nginx మీ కోసం రీలోడ్ చేస్తుంది. కానీ --webroot మరియు --standalone రన్‌లు అలా చేయవు. కాబట్టి పునరుద్ధరణ విజయవంతం అయినప్పటికీ, బ్రౌజర్ ఇంకా గడువు తీరుతున్న సర్టిఫికేట్‌నఁ చూస్తుంది. /etc/letsencrypt/renewal-hooks/deploy/‌లోకి nginx -t && systemctl reload nginx నఁ అమలు చేసే ఎగ్జిక్యూటబుల్ స్క్రిప్ట్‌నఁ ఉంచండి. ప్రతి విజయవంతమైన పునరుద్ధరణ తర్వాత అది ట్రిగ్గర్ అవుతుంది.

certbot renew --dry-run పునరుద్ధరణ పని చేస్తుందని నిరూపిస్తుందా?

చాలా వరకు. ఇది స్టేజింగ్ పరిసరంపై నిజమైన సవాలఁ అమలు చేస్తుంది — అదే ఫైర్‌వాల్, అదే DNS, అదే కోడ్ మార్గం — ఎలాంటి రేట్-లిమిట్ ఖర్చు లేకుండా మరియు డిస్క్‌కి ఏమీ రాయకుండా. కాబట్టి పాస్ అవ్వడం అంటే నెట్‌వర్క్ భాగం సరిగ్గా ఉందని అర్థం. అయితే, ఇది మీ డిప్లాయ్ హుక్ ట్రిగ్గర్ అవుతుందని విశ్వసనీయంగా నిరూపించదు. దాన్నఁ వేరేగా పరీక్షించండి: హుక్ స్క్రిప్ట్‌నఁ మాన్యువల్‌గా అమలు చేసి sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf తనిఖీ చేయండి.

#certbot#lets-encrypt#nginx#tls#ubuntu#systemd