Ubuntu 24.04 లో nginx కోసం Certbot ఇన్‌స్టాల్ చేయడం

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 అనేది మీ nginx కాన్ఫిగరేషన్కు Certbot దూరంగా ఉండాలనుకున్నప్పుడు సరైనది. ఉదాహరణకు, మీరు దాన్ని టెంప్లేట్ నుండి జనరేట్ చేసి, 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"

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

సర్టిఫికెట్ ఉనికిలోకి రాకముందు, వచ్చిన తర్వాత కూడా పనిచేసే సర్వర్ బ్లాక్

కోడి-గుడ్డు సమస్య: లేని ఫైల్ను సూచించే ssl_certificate తో nginx ప్రారంభం కావడానికి నిరాకరిస్తుంది, మరియు 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 ప్రొవైడర్ API ఆధారాలు అవసరం, అందుకే ప్రొవైడర్ ప్లగిన్‌లు ఉన్నాయి. పూర్తి వైల్డ్‌కార్డ్ సర్టిఫికెట్ వివరణ TXT రికార్డు మెకానిక్స్ మరియు మాన్యువల్ మోడ్‌లో రెన్యువల్ ఉచ్చును వివరిస్తుంది; క్లౌడ్‌ఫ్లేర్ కోసం సంక్షిప్త వెర్షన్ క్రింద ఉంది.

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

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

# /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'

మీ షెల్ దాన్ని గ్లాబ్ చేయకుండా ఉండేందుకు వైల్డ్‌కార్డ్‌ను కోట్ చేయండి. HTTP-01 చేయలేని దాన్ని DNS-01 పరిష్కరిస్తుంది: పబ్లిక్ పోర్ట్ 80 లేని హోస్ట్‌లు, ఒక అంతర్గత సేవ, VPS పై స్వీయ-హోస్టెడ్ వైర్‌గార్డ్ 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 యొక్క స్టేజింగ్ వాతావరణంపై పూర్తి సవాలును నడుపుతుంది: అదే కోడ్ మార్గం, అదే ఫైర్‌వాల్, అదే DNS, రేటు-పరిమితి ఖర్చు లేదు, డిస్క్‌కు ఏమీ వ్రాయబడదు. ఈరోజు ఇది విజయవంతమైతే, 60 రోజుల్లో జరిగే గమనింపబడని పునరుద్ధరణ కూడా విజయవంతమవుతుంది, దాని కింద ఉన్న బాక్స్ గురించి ఏమీ మారదని ఊహిస్తే.

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

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

Could not bind to IPv4 or IPv6., --standalone nginx ఇప్పటికే పోర్ట్ 80ని కలిగి ఉన్నప్పుడు. --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.

nginx కోసం Ubuntu 24.04లో apt లేదా snap, ఏ 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 రన్లు చేయవు, కాబట్టి బ్రౌజర్ ఇప్పటికీ గడువు ముగుస్తున్న సర్టిఫికేట్ను చూస్తుండగానే పునరుద్ధరణ విజయవంతం కావచ్చు. nginx -t && systemctl reload nginx రన్ చేసే ఎక్జిక్యూటబుల్ స్క్రిప్ట్ను /etc/letsencrypt/renewal-hooks/deploy/ లో ఉంచండి, మరియు అది ప్రతి విజయవంతమైన పునరుద్ధరణ తర్వాత అమలవుతుంది.

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

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