คู่มือติดตั้ง SSL ฟรีด้วย Let's Encrypt บน DigitalOcean 2026

A practical guide to installing free SSL certificates with Let's Encrypt and Certbot on a DigitalOcean Droplet, covering issuance, auto-renewal, and troubleshooting.

การเข้ารหัส HTTPS กลายเป็นมาตรฐานขั้นต่ำของเว็บไซต์ยุคใหม่ ไม่ว่าจะเป็นเรื่อง SEO ความน่าเชื่อถือ หรือคำเตือนของเบราว์เซอร์ที่ขึ้นทันทีหากเว็บไม่มี SSL Let's Encrypt คือ Certificate Authority ที่ออกใบรับรอง SSL ให้ฟรีและอัตโนมัติ เหมาะกับ Droplet บน DigitalOcean ที่ต้องติดตั้งเองผ่าน Certbot บทความนี้อธิบายขั้นตอนตั้งแต่ติดตั้ง ออกใบรับรอง ตั้งค่า auto-renew ไปจนถึงวิธีแก้ปัญหาที่พบบ่อย

Let's Encrypt คืออะไร ฟรีจริงไหม

Let's Encrypt เป็น Certificate Authority (CA) ที่ไม่แสวงหากำไร ดำเนินการโดย Internet Security Research Group (ISRG) ก่อตั้งขึ้นเพื่อผลักดันให้เว็บทั้งอินเทอร์เน็ตใช้ HTTPS เป็นค่าเริ่มต้น โดยได้รับการสนับสนุนจากองค์กรใหญ่ เช่น Mozilla, EFF (Electronic Frontier Foundation), Cisco, Google Chrome และผู้ให้บริการ hosting อีกจำนวนมาก จุดเด่นที่สุดคือใบรับรอง SSL/TLS ที่ออกโดย Let's Encrypt ฟรี 100% ไม่มีค่าใช้จ่ายแอบแฝง ไม่ต้องผูกบัตรเครดิต และไม่มีข้อจำกัดเรื่องจำนวนโดเมนที่ใช้งานได้ (ภายใต้ rate limit ที่กำหนดไว้เพื่อป้องกันการใช้งานผิดวัตถุประสงค์) คำถามที่พบบ่อยคือ 'ฟรีจริงไหม แล้วทำไมถึงฟรี' คำตอบคือ Let's Encrypt ใช้ระบบอัตโนมัติเต็มรูปแบบผ่านโปรโตคอล ACME (Automatic Certificate Management Environment) ทำให้ต้นทุนดำเนินงานต่ำกว่า CA แบบดั้งเดิมที่ต้องมีเจ้าหน้าที่ตรวจสอบเอกสารด้วยมือ ใบรับรองที่ออกเป็นแบบ Domain Validation (DV) เท่านั้น คือยืนยันแค่ว่าคุณเป็นเจ้าของโดเมนจริง ไม่ใช่ Extended Validation (EV) หรือ Organization Validation (OV) ที่ต้องส่งเอกสารบริษัทยืนยันตัวตน ดังนั้นจึงไม่เหมาะกับเว็บธนาคารหรือองค์กรที่ต้องการแสดงชื่อบริษัทในแถบที่อยู่เบราว์เซอร์ แต่เพียงพอสำหรับเว็บไซต์ทั่วไป บล็อก ร้านค้าออนไลน์ขนาดเล็ก-กลาง หรือ API endpoint ข้อจำกัดสำคัญที่ต้องรู้คือใบรับรองมีอายุแค่ 90 วัน สั้นกว่าใบรับรองแบบซื้อทั่วไปที่มักอายุ 1 ปีขึ้นไปมาก เหตุผลคือ Let's Encrypt ต้องการบังคับให้ระบบ renew เป็นแบบอัตโนมัติ ลดความเสี่ยงจากใบรับรองที่ถูกขโมย private key แล้วยังใช้งานได้อยู่นาน หากตั้งค่า auto-renew ถูกต้องตั้งแต่แรก ผู้ดูแลระบบแทบไม่ต้องยุ่งกับเรื่องนี้อีกเลย สำหรับผู้ใช้ DigitalOcean มีทางเลือกหลายแบบในการเปิด HTTPS ขึ้นอยู่กับสถาปัตยกรรมที่ใช้ ถ้ารันเว็บบน Droplet เอง (self-managed) ต้องติดตั้ง Certbot เองตามที่บทความนี้จะอธิบาย แต่ถ้าใช้ App Platform ระบบจะออกใบรับรอง SSL ให้อัตโนมัติทันทีที่ผูกโดเมนแบบไม่ต้องทำอะไรเพิ่ม และถ้าใช้ Load Balancer หน้า Droplet หลายตัว DigitalOcean ก็มีฟีเจอร์ผูก Let's Encrypt certificate ให้อัตโนมัติผ่านหน้า Control Panel ได้เช่นกัน โดยไม่ต้องยุ่งกับ Certbot บน Droplet แต่ละตัวเลย บทความนี้จะโฟกัสที่การติดตั้งบน Droplet ด้วย Certbot ซึ่งเป็นวิธีที่ใช้กันแพร่หลายที่สุดและควบคุมได้ละเอียดที่สุด

Let's Encrypt is a non-profit Certificate Authority (CA) operated by the Internet Security Research Group (ISRG), founded to push the entire internet toward HTTPS by default. It's backed by major organizations including Mozilla, EFF (Electronic Frontier Foundation), Cisco, Google Chrome, and numerous hosting providers. Its greatest strength is that SSL/TLS certificates issued by Let's Encrypt are 100% free—no hidden charges, no credit card required, and no limits on the number of domains you can use (subject to rate limiting to prevent abuse). A common question is: "Is it really free? Why?" The answer is that Let's Encrypt relies on full automation via the ACME protocol (Automatic Certificate Management Environment), dramatically reducing operational costs compared to traditional CAs that require staff to manually review documents. Certificates issued are Domain Validation (DV) only, meaning verification that you own the domain—not Extended Validation (EV) or Organization Validation (OV), which require company documents to display the business name in the browser's address bar. This makes them unsuitable for banks or organizations needing to display company identity, but perfectly adequate for typical websites, blogs, small-to-medium e-commerce shops, or API endpoints. One critical limitation to know: certificates expire after just 90 days—much shorter than typical purchased certificates (often 1+ years). This short lifespan is intentional: Let's Encrypt enforces automatic renewal to reduce risk from compromised private keys remaining in use for extended periods. With proper auto-renewal configuration from the start, system administrators barely need to think about it again. For DigitalOcean users, there are multiple ways to enable HTTPS depending on your architecture. Running a web server directly on a Droplet (self-managed) requires installing Certbot as this guide explains. App Platform handles SSL certificate issuance and renewal automatically the moment you bind a custom domain. Using a Load Balancer in front of multiple Droplets? DigitalOcean's Load Balancer has a built-in feature to automatically bind Let's Encrypt certificates via the Control Panel—no need to manage Certbot on each Droplet. This guide focuses on Droplet-based installation with Certbot, the most widely used and flexible approach.

• Let's Encrypt ออกใบรับรองฟรี 100% ไม่มีค่าใช้จ่ายแอบแฝง
• รองรับเฉพาะ Domain Validation (DV) ไม่ใช่ EV/OV
• อายุใบรับรองสั้นเพียง 90 วัน ต้องตั้ง auto-renew
• DigitalOcean มี 3 ทาง: Droplet+Certbot, App Platform auto SSL, Load Balancer auto Let's Encrypt

ติดตั้ง Certbot บน Ubuntu/Debian

Certbot คือเครื่องมือ client อย่างเป็นทางการที่ EFF พัฒนาขึ้นเพื่อคุยกับ Let's Encrypt ผ่านโปรโตคอล ACME โดยอัตโนมัติ รองรับการติดตั้งบน Ubuntu และ Debian ได้ 2 วิธีหลัก คือผ่าน apt package manager และผ่าน snap ซึ่งเป็นวิธีที่ทีม Certbot แนะนำอย่างเป็นทางการในปัจจุบัน เพราะได้เวอร์ชันล่าสุดเสมอและอัปเดตอัตโนมัติ วิธีติดตั้งผ่าน apt (ใช้งานง่าย เหมาะกับ Droplet ที่ต้องการความเรียบง่าย) เริ่มจากอัปเดต package list ก่อนด้วย sudo apt update จากนั้นติดตั้ง Certbot พร้อม plugin สำหรับเว็บเซิร์ฟเวอร์ที่ใช้ ถ้าใช้ Nginx ให้รัน sudo apt install certbot python3-certbot-nginx ถ้าใช้ Apache ให้รัน sudo apt install certbot python3-certbot-apache plugin เหล่านี้ทำหน้าที่แก้ไข config ของเว็บเซิร์ฟเวอร์ให้อัตโนมัติหลังออกใบรับรองสำเร็จ ไม่ต้องแก้ไฟล์ config เองด้วยมือ อีกวิธีคือติดตั้งผ่าน snap ซึ่งเป็นวิธีที่เว็บทางการของ Certbot (certbot.eff.org) แนะนำเป็นอันดับแรก เริ่มจากตรวจสอบว่ามี snapd ติดตั้งอยู่หรือไม่ (Ubuntu มีมาให้ในตัวอยู่แล้ว) จากนั้นรัน sudo snap install --classic certbot เพื่อติดตั้ง แล้วสร้าง symlink ให้เรียกใช้คำสั่ง certbot จากที่ไหนก็ได้ด้วย sudo ln -s /snap/bin/certbot /usr/bin/certbot ก่อนออกใบรับรอง ต้องตรวจสอบให้แน่ใจว่า Droplet เปิด port 80 (HTTP) และ 443 (HTTPS) ให้ traffic ผ่านเข้ามาได้ เพราะ Let's Encrypt ต้องเข้าถึง web server ผ่าน port 80 เพื่อยืนยันความเป็นเจ้าของโดเมน (HTTP-01 challenge) ถ้าใช้ ufw บน Ubuntu สามารถเปิดได้ง่ายด้วยคำสั่ง sudo ufw allow 'Nginx Full' สำหรับ Nginx หรือ sudo ufw allow 'Apache Full' สำหรับ Apache ซึ่งจะเปิดทั้ง port 80 และ 443 พร้อมกัน หากใช้ DigitalOcean Cloud Firewall แทนหรือเสริมกับ ufw (ฟีเจอร์นี้ใช้งานฟรี ไม่มีค่าใช้จ่ายเพิ่ม) ต้องเข้าไปเพิ่มกฎ Inbound rule อนุญาต TCP port 80 และ 443 จาก Anywhere ในหน้า Control Panel ด้วย ไม่เช่นนั้นแม้ ufw จะเปิดแล้ว การขอใบรับรองก็จะ timeout เพราะ Cloud Firewall บล็อกอยู่ชั้นนอก ทดสอบว่าติดตั้งสำเร็จด้วยคำสั่ง certbot --version

• apt: sudo apt install certbot python3-certbot-nginx (หรือ python3-certbot-apache)
• snap (แนะนำโดยทีม Certbot): sudo snap install --classic certbot
• เปิด port 80/443 ทั้งใน ufw และ DigitalOcean Cloud Firewall (ฟรี)

ออกใบรับรองสำหรับ Nginx/Apache

เมื่อติดตั้ง Certbot และ plugin เรียบร้อยแล้ว ขั้นตอนออกใบรับรองทำได้ในคำสั่งเดียว โดย Certbot จะจัดการทุกอย่างให้อัตโนมัติ ตั้งแต่ยืนยันโดเมน ขอใบรับรอง ไปจนถึงแก้ไข config เว็บเซิร์ฟเวอร์ สำหรับ Nginx ให้รันคำสั่ง sudo certbot --nginx -d example.com -d www.example.com โดยสามารถระบุหลายโดเมนหรือ subdomain ในคำสั่งเดียวด้วยการเติม -d ซ้ำ เหมาะกับกรณีที่ต้องการให้ทั้ง apex domain และ www ใช้ certificate เดียวกัน (SAN certificate) สำหรับ Apache ใช้คำสั่งเดียวกันแต่เปลี่ยน flag เป็น sudo certbot --apache -d example.com -d www.example.com ระหว่างรันคำสั่งครั้งแรก Certbot จะถามข้อมูลเพิ่มเติมแบบ interactive คือ อีเมลสำหรับแจ้งเตือนก่อนใบรับรองหมดอายุและแจ้งเตือนด้านความปลอดภัย ต้องกดยอมรับ Terms of Service ของ Let's Encrypt และมีตัวเลือกว่าจะ redirect traffic จาก HTTP ไป HTTPS อัตโนมัติหรือไม่ (แนะนำให้เลือก redirect เพื่อบังคับให้ผู้ใช้เข้าเว็บผ่าน HTTPS เสมอ) หลังจากตอบคำถามครบ Certbot จะแก้ไขไฟล์ config ของ Nginx หรือ Apache ให้อัตโนมัติ เพิ่ม server block สำหรับ port 443 พร้อมชี้ path ไปยังไฟล์ certificate และ private key ที่เก็บอยู่ใน /etc/letsencrypt/live/example.com/ กรณีที่ไม่ต้องการให้ Certbot แก้ไข config เว็บเซิร์ฟเวอร์เอง เช่น ใช้ web server ตัวอื่นที่ไม่มี plugin รองรับ หรือมี config ที่ซับซ้อนอยู่แล้วและต้องการควบคุมเอง สามารถใช้โหมด certonly แทน เช่น sudo certbot certonly --nginx -d example.com จะออกใบรับรองให้เฉยๆ โดยไม่แก้ config หรือใช้ sudo certbot certonly --standalone -d example.com ซึ่งจะเปิด web server ชั่วคราวของตัวเองบน port 80 เพื่อยืนยันโดเมน เหมาะกับกรณีที่ไม่มี web server รันอยู่เลยหรือต้องการออกใบรับรองสำหรับ non-web service เช่น mail server หรือ custom application หลังออกใบรับรองสำเร็จ ให้ตรวจสอบด้วยการเปิดเว็บผ่าน https://example.com ควรเห็นสัญลักษณ์แม่กุญแจในเบราว์เซอร์ หรือตรวจสอบผ่านคำสั่ง sudo certbot certificates เพื่อดูรายการใบรับรองทั้งหมดที่ออกไว้บน Droplet พร้อมวันหมดอายุ

• Nginx: sudo certbot --nginx -d example.com -d www.example.com
• Apache: sudo certbot --apache -d example.com
• โหมด certonly --standalone สำหรับ non-web service

ตั้งค่า Auto-renew ใบรับรอง

เนื่องจากใบรับรองของ Let's Encrypt มีอายุเพียง 90 วัน การตั้งค่า auto-renew จึงเป็นขั้นตอนที่สำคัญไม่แพ้การออกใบรับรองครั้งแรก ข่าวดีคือตั้งแต่เวอร์ชันที่ติดตั้งผ่าน apt หรือ snap ในปัจจุบัน Certbot จะติดตั้ง scheduled task ให้อัตโนมัติทันทีหลังติดตั้งเสร็จ โดยไม่ต้องตั้งค่าเพิ่มเอง ถ้าติดตั้งผ่าน snap ระบบจะสร้าง systemd timer ให้อัตโนมัติ ตรวจสอบสถานะได้ด้วยคำสั่ง systemctl status certbot.timer ซึ่งปกติจะรันตรวจสอบวันละ 2 ครั้ง และจะ renew เฉพาะใบรับรองที่เหลืออายุน้อยกว่า 30 วันเท่านั้น (ใบรับรองที่ยังไม่ใกล้หมดอายุจะถูกข้ามไป ไม่เปลืองโควตา rate limit) ถ้าติดตั้งผ่าน apt บาง distro จะใช้ cron job แทนซึ่งอยู่ที่ /etc/cron.d/certbot ตรวจสอบเนื้อหาได้ด้วย cat /etc/cron.d/certbot สิ่งที่ควรทำเสมอหลังตั้งค่าเสร็จคือทดสอบว่ากระบวนการ renew ทำงานถูกต้องโดยไม่ต้องรอให้ใบรับรองใกล้หมดอายุจริง ใช้คำสั่ง sudo certbot renew --dry-run ซึ่งจะจำลองขั้นตอน renew ทั้งหมดโดยไม่ขอใบรับรองจริงจาก Let's Encrypt (ไม่กระทบ rate limit) หากคำสั่งนี้รันผ่านโดยไม่มี error แสดงว่าระบบ auto-renew พร้อมทำงานจริงเมื่อถึงเวลา จุดที่มักถูกมองข้ามคือหลัง renew สำเร็จ ต้องสั่งให้ web server โหลด certificate ใหม่ ไม่เช่นนั้น process ที่รันอยู่จะยังใช้ certificate เก่าในหน่วยความจำต่อไปจนกว่าจะ restart เอง Certbot แก้ปัญหานี้ด้วย hook script โดยสามารถเพิ่ม post-hook ให้ reload web server อัตโนมัติทุกครั้งที่ renew สำเร็จ เช่น ระบุตรงในคำสั่ง sudo certbot renew --deploy-hook "systemctl reload nginx" ซึ่งจะสั่ง reload Nginx แบบ graceful ไม่ตัดการเชื่อมต่อที่ค้างอยู่ ต่างจาก restart ที่จะตัดการเชื่อมต่อทั้งหมด สำหรับผู้ที่ต้องการควบคุม schedule เอง สามารถเพิ่ม cron job แบบ manual ได้เช่นกัน ตัวอย่างเช่น รันทุกวันเวลาเที่ยงคืนและเที่ยงวัน ด้วยบรรทัด 0 0,12 * * * root certbot renew --quiet --post-hook "systemctl reload nginx" ใน crontab แต่โดยทั่วไปไม่จำเป็นต้องทำเองเพราะ Certbot ตั้งให้อัตโนมัติอยู่แล้ว ควรตรวจสอบ log การ renew เป็นระยะที่ /var/log/letsencrypt/letsencrypt.log เพื่อความมั่นใจว่าไม่มีปัญหาสะสม

• Certbot ตั้ง auto-renew ให้อัตโนมัติ (systemd timer หรือ cron) ทันทีหลังติดตั้ง
• ทดสอบด้วย sudo certbot renew --dry-run โดยไม่กระทบ rate limit
• renew อัตโนมัติเฉพาะใบรับรองที่เหลืออายุน้อยกว่า 30 วัน
• ใช้ --deploy-hook "systemctl reload nginx" ให้ web server โหลด cert ใหม่แบบ graceful
• ตรวจ log ที่ /var/log/letsencrypt/letsencrypt.log เป็นระยะ

Troubleshoot ปัญหาที่พบบ่อย

จากการรีวิวหลายรอบ แม้ Certbot จะออกแบบมาให้ใช้งานง่าย แต่ก็มีปัญหาที่ผู้ใช้ DigitalOcean เจอบ่อยเป็นประจำ ปัญหาแรกและพบบ่อยที่สุดคือ 'Failed authorization procedure' หรือ timeout ระหว่างขอใบรับรอง สาเหตุหลักมักมาจาก port 80 ถูกบล็อกอยู่ ไม่ว่าจะจาก ufw บน Droplet เองที่ยังไม่ได้เปิด หรือจาก DigitalOcean Cloud Firewall ที่ตั้งไว้ระดับ network ก่อนถึง Droplet ต้องตรวจสอบทั้งสองชั้นพร้อมกัน เพราะเปิดแค่ ufw อย่างเดียวไม่พอถ้า Cloud Firewall ยังบล็อกอยู่ ทดสอบง่ายๆ ด้วยการรัน curl -I http://example.com จากเครื่องอื่นนอก network ของ DigitalOcean ว่าเชื่อมต่อผ่าน port 80 ได้จริงหรือไม่ก่อนรัน certbot ปัญหาที่สองคือ DNS ยังไม่ propagate หรือ A record ยังไม่ชี้มาที่ IP ของ Droplet ให้ถูกต้อง Let's Encrypt ต้องเข้าถึงโดเมนผ่านอินเทอร์เน็ตจริงเพื่อยืนยันความเป็นเจ้าของ ถ้า DNS ยังชี้ไปที่ hosting เก่าหรือยังไม่อัปเดต การขอใบรับรองจะล้มเหลวทันที ตรวจสอบด้วย dig example.com +short หรือ nslookup example.com ให้แน่ใจว่าผลลัพธ์ตรงกับ IP ของ Droplet ก่อนรัน certbot เสมอ ปัญหาที่สามคือชน rate limit ของ Let's Encrypt ซึ่งจำกัดไว้ที่ 50 ใบรับรองต่อโดเมนหลักต่อสัปดาห์ และ 5 ใบรับรองที่ซ้ำกันทุกประการ (duplicate certificate) ต่อสัปดาห์ มักเกิดจากการรันคำสั่ง certbot ซ้ำๆ ระหว่าง debug ปัญหาอื่น วิธีป้องกันคือใช้ flag --dry-run หรือ --staging ระหว่างทดสอบเสมอ ซึ่งชี้ไปที่ Let's Encrypt staging environment ที่ไม่มี rate limit เข้มงวดและออกใบรับรองที่เบราว์เซอร์ไม่เชื่อถือ (ใช้ทดสอบ flow เท่านั้น) เช่น sudo certbot certonly --staging -d example.com ปัญหาอื่นที่พบได้คือ error เกี่ยวกับ private key permission ผิดพลาดหลังย้ายไฟล์ certificate ข้าม Droplet ด้วยมือ ซึ่งไม่แนะนำให้ทำ เพราะไฟล์ในโฟลเดอร์ /etc/letsencrypt/ มี symlink เชื่อมโยงกันซับซ้อน หากต้องการย้าย ควรออกใบรับรองใหม่บน Droplet ปลายทางแทนการ copy ไฟล์ตรงๆ และสุดท้ายคือปัญหา mixed content หลังเปิด HTTPS แล้วเว็บยังโหลดไม่สมบูรณ์ ซึ่งมักเกิดจาก asset บางตัว (รูปภาพ, script, CSS) ยังฝัง URL แบบ http:// ตรงๆ ในโค้ด ต้องแก้เป็น relative path หรือ https:// ให้ครบ

• port 80 ถูกบล็อกจาก ufw หรือ DigitalOcean Cloud Firewall — ต้องเช็คทั้งสองชั้น
• DNS ยังไม่ชี้มาที่ Droplet — ตรวจด้วย dig example.com +short
• ชน rate limit 50 certs/สัปดาห์ — ใช้ --staging ระหว่างทดสอบ
• อย่า copy ไฟล์ /etc/letsencrypt/ ข้าม Droplet ตรงๆ

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

การติดตั้ง SSL ด้วย Certbot บน Droplet โดยตรงเหมาะกับหลายสถานการณ์ แต่ก็ไม่ใช่ทางเลือกเดียวเสมอไปในระบบนิเวศของ DigitalOcean จึงควรเข้าใจว่าเมื่อไหร่ควรเลือกวิธีไหน กรณีแรกคือเว็บไซต์หรือแอปพลิเคชันที่รันบน Droplet เดี่ยว (single server) ด้วย Nginx หรือ Apache เช่น เว็บ WordPress, บล็อกส่วนตัว, หรือ API backend ขนาดเล็ก-กลาง กรณีนี้ Certbot คือทางเลือกที่ตรงไปตรงมาที่สุด ติดตั้งครั้งเดียว auto-renew ทำงานเองตลอด ไม่มีค่าใช้จ่ายเพิ่มจาก DigitalOcean กรณีที่สองคือเมื่อมี Droplet หลายตัวอยู่หลัง Load Balancer ในกรณีนี้ไม่จำเป็นต้องติดตั้ง Certbot บนทุก Droplet เอง เพราะ DigitalOcean Load Balancer (เริ่มต้น $12/เดือน) มีฟีเจอร์ผูก Let's Encrypt certificate ให้อัตโนมัติผ่านหน้า Control Panel ได้เลย ระบบจะจัดการ renew ให้ที่ระดับ Load Balancer แทน ลดความซับซ้อนในการดูแลหลาย Droplet พร้อมกัน เหมาะกับสถาปัตยกรรมที่ scale แบบ horizontal กรณีที่สามคือเว็บไซต์ที่ต้องการ wildcard certificate เช่น ครอบคลุมทุก subdomain ของ *.example.com ในคราวเดียว ซึ่ง HTTP-01 challenge แบบปกติทำไม่ได้ ต้องใช้ DNS-01 challenge แทน โดยติดตั้ง plugin เพิ่มเติมชื่อ certbot-dns-digitalocean ที่เชื่อมกับ DigitalOcean API โดยตรง (ใช้ Personal Access Token) เพื่อให้ Certbot สร้าง DNS TXT record ยืนยันความเป็นเจ้าของโดเมนแบบอัตโนมัติโดยไม่ต้องเปิด port 80 เลย เหมาะกับทีมที่มี subdomain จำนวนมากและต้องการจัดการ certificate แบบรวมศูนย์ ในทางกลับกัน ถ้าใช้ App Platform ของ DigitalOcean แทนการรัน Droplet เอง แทบไม่ต้องยุ่งกับ Certbot เลย เพราะระบบออกและ renew ใบรับรองให้อัตโนมัติทันทีที่ผูก custom domain เข้ากับแอป เหมาะกับทีมที่ต้องการลดภาระ DevOps และไม่จำเป็นต้องควบคุม server ระดับ OS เอง สรุปคือควรเลือกวิธีที่เข้ากับสถาปัตยกรรมจริงของระบบ ไม่ใช่ใช้ Certbot บน Droplet เป็นค่าเริ่มต้นเสมอไปในทุกกรณี

• Droplet เดี่ยวรัน Nginx/Apache — Certbot คือทางเลือกตรงไปตรงมาที่สุด
• หลาย Droplet หลัง Load Balancer — ใช้ Let's Encrypt integration ของ Load Balancer แทน (เริ่ม $12/เดือน)
• ต้องการ wildcard cert — ใช้ DNS-01 ผ่าน certbot-dns-digitalocean
• ใช้ App Platform — ได้ SSL อัตโนมัติโดยไม่ต้องยุ่งกับ Certbot เลย

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

จากการรีวิวหลายรอบ นอกจากปัญหาทางเทคนิคที่กล่าวถึงในหัวข้อ Troubleshoot ยังมีข้อผิดพลาดเชิงกระบวนการ (process-level mistakes) ที่ผู้ดูแลระบบมักพลาดโดยไม่รู้ตัว ซึ่งนำไปสู่ปัญหาใหญ่กว่าตอนออกใบรับรองครั้งแรกเสียอีก ข้อผิดพลาดแรกคือลืมทดสอบ auto-renew หลังตั้งค่าเสร็จ หลายคนติดตั้ง Certbot ออกใบรับรองสำเร็จแล้วก็ไม่ได้กลับมาตรวจสอบอีกเลย จนกระทั่ง 90 วันผ่านไปใบรับรองหมดอายุจริง เว็บไซต์ขึ้น warning หน้าเบราว์เซอร์แบบไม่ทันตั้งตัว ทางแก้คือต้องรัน sudo certbot renew --dry-run ทันทีหลังติดตั้งเสร็จเสมอ และตั้ง monitoring แยกต่างหาก เช่นใช้ DigitalOcean Monitoring หรือ Uptime Check (ฟรี 1 รายการต่อบัญชี) คอยแจ้งเตือนถ้าเว็บไซต์เริ่มมีปัญหา SSL ข้อผิดพลาดที่สองคือ rebuild หรือทำลาย Droplet โดยไม่ backup โฟลเดอร์ /etc/letsencrypt/ ก่อน ทำให้ต้องขอใบรับรองใหม่ทั้งหมดหลังสร้าง Droplet ใหม่ ซึ่งไม่ใช่ปัญหาใหญ่มากถ้าไม่ชน rate limit แต่ก็เสียเวลาโดยไม่จำเป็น ทางแก้คือสร้าง DigitalOcean Snapshot ของ Droplet เป็นประจำ (ราคา $0.06/GiB ต่อเดือน) ซึ่งจะรวมโฟลเดอร์ certificate ไว้ในนั้นด้วยอัตโนมัติ หรืออย่างน้อยที่สุดให้ backup โฟลเดอร์นี้แยกไว้ต่างหากก่อนทำการเปลี่ยนแปลงใหญ่ใดๆ ข้อผิดพลาดที่สามคือแก้ config เว็บเซิร์ฟเวอร์ด้วยมือหลัง Certbot ตั้งค่าให้แล้ว โดยไม่รู้ว่า Certbot จัดการ block SSL ให้อัตโนมัติ ทำให้เกิด config ซ้อนกันหรือขัดแย้งกัน (conflicting server block) วิธีที่ปลอดภัยกว่าคือปล่อยให้ Certbot จัดการส่วน SSL ทั้งหมด แล้วแก้เฉพาะส่วน location/proxy_pass อื่นๆ ที่ไม่เกี่ยวกับ certificate เอง ข้อผิดพลาดสุดท้ายที่พบบ่อยคือลืมเปิด port 443 ใน DigitalOcean Cloud Firewall หลังเพิ่มกฎใน ufw แล้ว เข้าใจผิดว่าตั้งค่าชั้นเดียวพอ ทำให้ auto-renew ทำงานได้ปกติ (เพราะใช้ port 80) แต่ผู้ใช้จริงเข้าเว็บผ่าน HTTPS ไม่ได้เพราะ port 443 ยังถูกบล็อกอยู่ที่ระดับ network ก่อนถึง Droplet ทางแก้คือตรวจสอบกฎทั้งใน ufw (sudo ufw status) และ Cloud Firewall ในหน้า Control Panel ให้ตรงกันเสมอทุกครั้งที่มีการเปลี่ยนแปลง

• ลืมทดสอบ auto-renew — รันและตรวจสอบทันทีหลังติดตั้ง
• rebuild Droplet โดยไม่ backup /etc/letsencrypt/ — ใช้ Snapshot ($0.06/GiB/เดือน)
• แก้ config เว็บเซิร์ฟเวอร์ทับส่วนที่ Certbot จัดการ — เกิด config ขัดแย้งกัน
• เปิด port 443 แค่ใน ufw ไม่เปิดใน Cloud Firewall — เว็บเข้า HTTPS ไม่ได้

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

หลังตั้งค่า Let's Encrypt SSL บน Droplet เสร็จเรียบร้อยแล้ว มีแนวทางเพิ่มเติมที่ช่วยให้ระบบมั่นคงและปลอดภัยในระยะยาว ไม่ใช่แค่ทำให้ใช้งานได้ครั้งแรกแล้วจบ ข้อแรกคือใช้ flag --staging เสมอระหว่างทดสอบหรือ debug config ใหม่ๆ ก่อนขอใบรับรองจริง เพื่อไม่ให้ชน rate limit ของ production environment โดยไม่จำเป็น โดยเฉพาะเมื่อต้องทดลองซ้ำหลายรอบระหว่างปรับแต่ง Nginx/Apache config ข้อสองคือเปิดใช้งาน HSTS (HTTP Strict Transport Security) หลังยืนยันว่า HTTPS ทำงานเสถียรดีแล้ว ด้วยการเพิ่ม header Strict-Transport-Security ใน config เว็บเซิร์ฟเวอร์ เพื่อบังคับให้เบราว์เซอร์เชื่อมต่อผ่าน HTTPS เท่านั้นในครั้งถัดไปแม้ผู้ใช้จะพิมพ์ URL แบบ http:// ก็ตาม แต่ควรทดสอบให้แน่ใจก่อนว่าทุก subdomain รองรับ HTTPS ครบ เพราะ HSTS ที่ตั้งผิดอาจทำให้เข้าเว็บไม่ได้ชั่วคราว ข้อสามคือตั้ง monitoring แยกสำหรับตรวจสอบวันหมดอายุของ certificate ไม่ควรพึ่งพา auto-renew ของ Certbot เพียงอย่างเดียวโดยไม่มีการแจ้งเตือนสำรอง ใช้ DigitalOcean Monitoring หรือบริการ third-party ตรวจสอบ SSL expiry ควบคู่กันไป เพื่อให้รู้ทันทีถ้า renew ล้มเหลวด้วยเหตุผลใดก็ตาม ข้อสี่คือใช้ --deploy-hook แทนการ restart web server ด้วยมือทุกครั้งหลัง renew เพื่อให้ระบบ reload certificate ใหม่แบบอัตโนมัติและ graceful ไม่ตัดการเชื่อมต่อผู้ใช้ที่กำลังใช้งานอยู่ ข้อห้าคือ backup โฟลเดอร์ /etc/letsencrypt/ เป็นประจำผ่าน DigitalOcean Snapshot หรือ Volume แยก โดยเฉพาะก่อนทำการเปลี่ยนแปลงใหญ่ เช่น อัปเกรด OS หรือย้าย Droplet ไปยัง region อื่น เพื่อลดความเสี่ยงต้องขอใบรับรองใหม่ทั้งหมดโดยไม่จำเป็น ข้อสุดท้ายคืออัปเดต Certbot ให้เป็นเวอร์ชันล่าสุดเสมอ โดยเฉพาะถ้าติดตั้งผ่าน snap ซึ่งจะอัปเดตให้อัตโนมัติอยู่แล้ว แต่ถ้าติดตั้งผ่าน apt ควรตรวจสอบเป็นระยะด้วย sudo apt update && sudo apt upgrade certbot เพราะ Let's Encrypt และ ACME protocol มีการปรับปรุงมาตรฐานความปลอดภัยอยู่เรื่อยๆ การใช้เวอร์ชันเก่าเกินไปอาจเจอปัญหาความเข้ากันได้ในอนาคต

• ใช้ --staging เสมอระหว่างทดสอบ ไม่ชน rate limit จริง
• เปิด HSTS หลังยืนยัน HTTPS เสถียรแล้วเท่านั้น
• ตั้ง monitoring แยกตรวจ SSL expiry ไม่พึ่ง auto-renew อย่างเดียว
• ใช้ --deploy-hook ให้ reload web server แบบ graceful
• backup /etc/letsencrypt/ ผ่าน Snapshot ก่อนเปลี่ยนแปลงใหญ่เสมอ

รับ $200 Free Credit →