התקנת Certbot עבור Apache ב-Ubuntu 24.04

מה אתם בונים

אתר Apache על גבי Ubuntu 24.04 המגיב ב-HTTPS עם תעודת Let's Encrypt חינמית המוכרת על ידי דפדפנים. התעודה מונפקת על ידי Certbot ומחודשת אוטומטית באמצעות טיימר של systemd, כך שלא תצטרכו לעסוק בכך שוב. הפקודה שמבצעת את העבודה מורכבת משורה אחת בלבד. כל מה שמשתבש קורה לפני הרצת שורה זו: הגדרת vhost ללא ServerName, פורט 80 חסום ב-firewall של ספק הענן, או DNS שעדיין מצביע על השרת הישן. לכן, מדריך זה מתמקד בעיקר בתנאים המוקדמים ומציין את מחרוזת השגיאה המדויקת שכל תקלה מציגה.

שתי הערות לגבי היקף המדריך. אם שרת האינטרנט שלכם הוא nginx, התהליך דומה במבנהו אך התוסף וקובצי התצורה שונים; השתמשו ב-גרסת המדריך עבור nginx. אם השירות שאתם מאבטחים מיועד לשימוש פנימי בלבד – למשל לוח ניהול בכתובת פרטית או סביבת staging שאיש אינו ניגש אליה – אינכם זקוקים כלל לרשות אישורים (CA); תעודה בחתימה עצמית דורשת פחות הגדרות ועובדת גם ללא חיבור לאינטרנט.

דרישות קדם, ושלוש הדרכים שבהן התהליך נכשל עוד לפני הרצת Certbot

• Apache כבר מגיש את האתר שלכם ב-HTTP רגיל. התוסף של Certbot עבור Apache עורך אתר קיים; הוא אינו יוצר אתר חדש. אם אתם מתחילים מ-VPS ריק, בנו תחילה את ה-LAMP stack on Ubuntu 24.04 וחזרו לכאן; מדריך זה הוא פרק ה-TLS החסר בו.
• שם מתחם ציבורי עם רשומת A שמצביעה לכתובת ה-VPS שלכם. אתגר ה-HTTP-01 של Let’s Encrypt מחייב ששרתי האימות שלהם יתחברו לשרת שלכם מהאינטרנט: לא ניתן להשתמש בסביבת מעבדה ביתית (homelab) מאחורי NAT ללא הפניית פורטים, לא ב-.local, ולא בכתובות IP חשופות. ה-dig +short example.com חייב להחזיר את כתובת ה-VPS שלכם, ואם שיניתם את ה-DNS בשעה האחרונה, המתינו לסיום ה-TTL של הרשומה הישנה לפני הנפקת התעודה.
• אם קיימת רשומת AAAA, היא חייבת להיות תקינה. Let’s Encrypt מעדיפה IPv6 כאשר קיימת רשומת AAAA, לכן רשומת AAAA מיושנת תגרום לכשל באימות גם אם ה-curl מהמחשב הנייד שלכם, שסביר להניח שמשתמש ב-IPv4, עובד כראוי. פרסמו רשומת AAAA תקינה או אל תפרסמו רשומה כלל.

פורטים 80 ו-443 חייבים להיות פתוחים ב-ufw וגם ב-firewall של ספק התשתית שלכם; ברוב לוחות הניהול של חברות האחסון יש firewall נוסף שהמערכת אינה רואה. אימות HTTP-01 מתבצע ספציפית דרך פורט 80; לא ניתן להריץ זאת בפורט 443 בלבד.

sudo ufw allow "Apache Full"
sudo ufw status

כאשר התנאים הללו מתקיימים, התהליך כולו אורך כ-15 דקות, מתוכן 10 דקות מוקדשות לקריאה.

Snap או apt עבור Certbot? בגרסה 24.04, השימוש ב-apt תקין לחלוטין

פרויקט Certbot עבר להפצה באמצעות snap לפני שנים מסיבה מוצדקת: חבילות ההפצה התיישנו. Ubuntu 20.04 הגיעה עם Certbot 0.40 ללא עדכונים, והפרויקט התעייף מניפוי באגים בני חמש שנים. בגרסה 24.04 סיבה זו אינה קיימת עוד; המאגרים כוללים את Certbot 2.9.0, גרסה עדכנית, ו-unattended-upgrades דואג לעדכוני אבטחה. ההמלצה שלי למערכת הפעלה זו: השתמשו ב-apt. כך נמנעים מה-daemon של snapd, תוסף ה-Apache מותקן באותה פעולה, וטיימר החידוש משתלב ב-systemd בדרך הסטנדרטית של Debian.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

התוצאה הנכונה: certbot 2.9.0. החבילה python3-certbot-apache היא התוסף שקורא ועורך את קובצי התצורה של Apache; בלעדיו, certbot --apache ייכשל עם The requested apache plugin does not appear to be installed.

השימוש ב-snap עדיין נכון בשני מקרים: אם אתם רוצים את הגרסה החדשה ביותר של Certbot ביום שחרורה, או אם אתם זקוקים לתוסף DNS שמופץ רק כ-snap (כך המצב עבור כמה מתוספי ספקי ה-certbot-dns-*). אם בחרתם בדרך זו:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

באיזו אפשרות שלא תבחרו, לעולם אל תריצו את שתיהן. שתי התקנות משמען שני מתזמני חידוש שנאבקים על /etc/letsencrypt, וה-certbot שה-shell שלכם מוצא ב-PATH עשוי שלא להיות זה שמנהל את התעודות שלכם. שורת ה-apt remove לעיל אינה קישוט אופציונלי.

ה-vhost ש-Certbot עורך חייב להיות קיים כבר, ו-ServerName הוא המפתח

certbot --apache פועל על ידי איתור ה-virtual host בפורט 80 שה-ServerName או ה-ServerAlias שלו תואמים לכל דומיין -d שאתם מעבירים, מוכיח שליטה בדומיין דרכו, ואז כותב גרסת SSL תאומה לאותו vhost. ללא ServerName תואם, לא תהיה התאמה, וה-000-default.conf המוגדר כברירת מחדל ב-Ubuntu מגיע עם ServerName כשהוא מוער (commented out). השורה המוערת הבודדת הזו היא הסיבה הנפוצה ביותר לכך שהפקודה המרכזית במדריך זה נכשלת.

לכן, לפני שנוגעים ב-Certbot, תנו לאתר שם vhost מבוסס-שם תקין. צרו את /etc/apache2/sites-available/example.com.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

הפעילו אותו וודאו ש-Apache גם מנתח אותו וגם מנתב את השם אליו:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest חייב להדפיס Syntax OK. אם הוא מדפיס גם AH00558: apache2: Could not reliably determine the server's fully qualified domain name, זו אזהרה לגבי ה-ServerName הגלובלי, לא ה-vhost שלכם; היא אינה מזיקה כאן, וניתן להשתיק אותה באמצעות echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

הפלט של -S הוא הבדיקה הקובעת. אתם מחפשים שורה כמו port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) עם alias www.example.com מתחתיה; Apache מדווח על ה-symlink של sites-enabled שהוא קרא בפועל, לא על הקובץ שערכתם ב-sites-available. אם example.com לא מופיע תחת פורט 80, גם Certbot לא ימצא אותו.

הנפקת התעודה: certbot --apache

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

ההרצה הראשונה מבקשת שלושה פרטים: כתובת דוא"ל (משמשת עבור חשבון ה-ACME שלכם ועבור התראות דחופות מה-CA;‏ Let's Encrypt אינה שולחת עוד התראות על פקיעת תוקף, לכן ניטור החידושים הוא באחריותכם), הסכמה לתנאי השימוש של Let's Encrypt, והחלטה אם לשתף את כתובת הדוא"ל עם ה-EFF. אין יותר שאלה בנוגע להפניות: החל מגרסה 2.0 של Certbot, מתקין ה-Apache מבצע הפניה מ-HTTP ל-HTTPS כברירת מחדל, וזהו המצב הרצוי. העבירו את הדגל --no-redirect אם אתם באמת זקוקים ל-HTTP רגיל כדי להמשיך ולהגיש תוכן.

הצלחה נראית כך, ומומלץ לקרוא את הפלט במלואו ולא רק לסרוק אותו בעיניים:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

מאחורי הודעה זו, Certbot ביצע ארבע פעולות: הפעיל את המודול ssl של Apache אם לא היה פעיל, יצר את example.com-le-ssl.conf, עותק של ה-vhost שלכם ב-*:443 הכולל את SSLEngine on ואת נתיבי התעודה, הפעיל אותו, והוסיף בלוק RewriteRule ל-vhost המקורי בפורט 80 שמבצע הפניית 301 לכל תעבורת ה-HTTPS. קובץ ה-vhost המקורי שלכם ערוך, לא מוחלף, והתאום המאובטח (SSL) נמצא לצדו, שם תוכלו לקרוא כל שורה שנוספה.

היכן מאוחסנת התעודה בפועל, ומדוע לעולם אין להעתיק אותה

כל הקבצים ממוקמים תחת /etc/letsencrypt/live/example.com/: fullchain.pem (התעודה בצירוף שרשרת הביניים, הקובץ שאליו השרתים צריכים להפנות), privkey.pem (המפתח הפרטי, בעל הרשאות קריאה ל-root בלבד), בנוסף ל-cert.pem ו-chain.pem עבור תוכנות הדורשות את הרכיבים בנפרד. אלו הם קישורים סימבוליים (symlinks) המצביעים לתוך /etc/letsencrypt/archive/, והעקיפה הזו היא מנגנון החידוש: תהליך החידוש כותב קבצים חדשים לתוך archive/ ומעדכן את הקישורים הסימבוליים. הפנו כל תוכנה אחרת לנתיבי live/ והיא תזהה את החידושים באופן אוטומטי; העתקת הקבצים למקום אחר תגרום להשבתת השירות בעוד 90 יום.

קובץ נוסף שחשוב להכיר הוא /etc/letsencrypt/renewal/example.com.conf, המתעד כיצד הונפקה תעודה זו, את authenticator = apache, installer = apache, ואת שמות המתחם, כך שתהליך החידוש יוכל לחזור על הפעולה ללא התערבות, כולל טעינה מחדש של Apache לאחר מכן.

החידוש כבר מתוזמן, יש לוודא זאת, אין לבצע בנייה מחדש

תעודות Let’s Encrypt תקפות ל-90 יום כברירת מחדל, וחבילת ה-apt כבר התקינה את המנגנון הנדרש: טיימר של systemd המריץ את Certbot פעמיים ביום בזמנים אקראיים, ומחדש כל תעודה שנותרו לה פחות מ-30 יום לפקיעת תוקפה. אין להוסיף משימת cron נוספת; מתזמן שני רק יוסיף רעש ללוגים וחשיפה למגבלות קצב (rate-limit).

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

הפקודה הראשונה מציגה את הטיימר כפעיל, עם זמן NEXT ב-24 השעות הקרובות. לוח הזמנים הוא פעמיים ביום עם השהיה אקראית, כך שהזמן המדויק אינו צפוי במכוון (בהתקנת snap, הטיימר הוא snap.certbot.renew.timer). ה-dry run מבצע חזרה גנרלית מלאה על תהליך החידוש מול סביבת ה-staging של Let’s Encrypt; זהו אתגר אמיתי, ללא הנפקת תעודה וללא פגיעה במכסות ה-rate-limit. תוצאה תקינה מסתיימת ב:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

אם ה-dry run נכשל, החידוש האמיתי בעוד כ-60 יום ייכשל באותו אופן. יש לתקן זאת כעת, בעוד לתעודה הנוכחית נותרה מלוא תקופת חייה. הגורם השכיח ביותר הוא חוק firewall שנוסף לאחר ההנפקה וחסם שוב את פורט 80.

אימות באמצעות curl ובדיקת פרטי המנעול

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

הפקודה הראשונה אמורה להחזיר HTTP/1.1 301 Moved Permanently עם header מסוג Location: https://example.com/, המציין את ההפניה (redirect) שהותקנה על ידי Certbot. הפקודה השנייה אמורה להחזיר HTTP/1.1 200 OK ללא שגיאות TLS מצד curl. הפקודה השלישית מדפיסה את המנפיק, שורת O = Let's Encrypt עם CN קצר כמו R12 או E7, ותאריך notAfter המרוחק כ-90 ימים קדימה. בדפדפן יופיע סמל המנעול, ולחיצה עליו תציג את אותו המנפיק. אם curl פועל כשורה אך הדפדפן מציג אזהרה, סביר להניח שאתם צופים בדף שמור במטמון (cache) או משתמשים בשם מארח (hostname) שגוי, ולא מדובר בבעיית תעודה.

ריבוי אתרים: תעודת SAN אחת או תעודה נפרדת לכל אתר

שתי השיטות עובדות; תהליך החידוש זהה בשתיהן. עבור אתרים שאינם קשורים זה לזה על אותו שרת, הריצו את פקודת ההנפקה פעם אחת לכל אתר. כל אתר יקבל ספרייה משלו תחת live/ וקובץ הגדרות חידוש נפרד, כך שתקלה בדומיין אחד לא תחסום את חידוש התעודות של האחרים. זוהי ברירת המחדל המומלצת.

עבור אתר אחד עם כמה שמות, כללו אותם בתעודת SAN אחת; תעודה בודדת יכולה להכיל עד 100 שמות. כבר ביצעתם זאת לעיל עם example.com ו-www.example.com. כדי להוסיף שם לתעודה קיימת במועד מאוחר יותר, הנפיקו אותה מחדש תוך ציון שם התעודה ורשימת השמות המלאה והחדשה:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot יזהה את השינוי בקבוצת הדומיינים, יבקש אישור להרחבת התעודה, ויחליף את התעודה הקיימת באותו נתיב live/, כך שלא יהיה צורך בשינויים נוספים. שימו לב שהרשימה מחליפה את הקודמת ולא מתווספת אליה: אם תשמיטו את www מהפקודה, התעודה החדשה תסיר אותו ללא התראה.

תעודות Wildcard מחייבות שימוש ב-DNS-01, ובדרך כלל אין בהן צורך

אתגר HTTP-01 אינו יכול להנפיק *.example.com, שכן הצבת קובץ בשרת אינטרנט מוכיחה שליטה על שם מארח (hostname) בודד, ולא על מרחב שמות שלם. תעודות Wildcard מחייבות את אתגר ה-DNS-01: הכלי Certbot מגדיר רשומת TXT ב-_acme-challenge.example.com, מה שדורש בפועל תוסף certbot-dns-* עם הרשאות API לספק ה-DNS שלכם, או עריכה ידנית של רשומות TXT בכל חידוש באמצעות --manual (תהליך מייגע, אל תבנו עליו). המדריך המלא, החל ממכניקת רשומות ה-TXT ועד לתוסף שמבצע חידוש ללא השגחה, נמצא ב-תעודות wildcard עם Certbot באמצעות DNS-01. עצה כנה: אם יש לכם ארבעה שמות מתחם משניים (subdomains) ידועים, תעודת SAN המפרטת את כל הארבעה פשוטה יותר מתעודת wildcard ואינה דורשת שמירת מפתחות API של DNS על השרת.

מצבי כשל והודעות שגיאה נפוצות

Certbot מסרב לעלות בגלל תצורה שגויה של Apache.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

התוסף מריץ את configtest לפני ביצוע כל שינוי, והוא נעצר אם Apache אינו תקין. ה-\ns המוצגים הם תיאור מדויק של השגיאה כפי ש-Certbot מדווח עליה. הריצו בעצמכם את sudo apache2ctl configtest: הפקודה תצביע על הקובץ ועל מספר השורה שבה קיימת שגיאה, בדרך כלל שגיאת הקלדה מעריכה ידנית, SSLCertificateFile שמצביע על נתיב שכבר אינו קיים, או מודול שצוין אך לא הופעל. תקנו את השגיאות עד שהפקודה תחזיר Syntax OK, ורק אז הריצו שוב את Certbot.

לא נמצא vhost התואם לשם המתחם.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

זהו כשל מסוג חוסר-ServerName שהוזכר קודם לכן, המזוהה בעת הנפקת התעודה. Certbot סרק את כל ה-vhost המוגדרים בפורט 80 עבור ServerName/ServerAlias התואם ל--d שלכם ולא מצא דבר. הפקודה sudo apache2ctl -S מציגה את הניתובים בפועל של Apache; הוסיפו את שורת ה-ServerName ל-vhost המתאים, בצעו reload ונסו שוב. מקרה דומה הוא כאשר האימות מגיע ל-vhost הלא נכון, ותגובת האתגר חוזרת כ-Invalid response ... 404 מכיוון שאתר אחר תפס את הבקשה. האבחון זהה, והכלי זהה: apache2ctl -S.

זמן ההמתנה לאימות חלף (Timeout).

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let's Encrypt לא הצליחה לפתוח חיבור TCP לפורט 80 בכתובת המפורסמת ב-DNS שלכם. לפי סדר סבירות: firewall של ספק התשתית (נפרד מ-ufw, מוגדר בלוח הבקרה של השרת), חוקי ufw המאפשרים רק 443 או רק SSH, רשומות DNS המצביעות עדיין על שרת ישן, או בעיית IPv6 מיושן (השרתים שלהם ניסו IPv6, בעוד השרת שלכם עונה רק ב-IPv4). בצעו בדיקה מחוץ ל-VPS: הפקודה curl -I http://example.com מהמחשב האישי שלכם תשחזר את מה שהמאמת שלהם רואה.

ניסיונות חוזרים הובילו לחריגה ממכסת התעבורה (Rate limit).

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt מאפשרת 5 אימותים כושלים לכל שם מתחם, לכל חשבון, בכל שעה. מאז העדכון של 2025 למנגנון המכסות, מדובר ב"דלי מתמלא" שצובר מחדש ניסיון אחד בערך כל 12 דקות. ניסיונות חוזרים מול firewall שבור ינצלו את המכסה במהירות. המתנה פותרת את הבעיה, אך הפתרון הנכון הוא התנהגותי: לאחר כל כשל, בצעו ניפוי שגיאות מול סביבת ה-staging עד להצלחה.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

שימו לב ל-certonly: ה---dry-run נתמך רק על ידי פקודות המשנה certonly ו-renew, בעוד שהשימוש ב-certbot --apache --dry-run לבדו יסרב לפעול ויציג את השגיאה --dry-run currently only works with the 'certonly' or 'renew' subcommands. הרצה במצב dry run מאמתת מול סביבת ה-staging, שיש לה מכסות נדיבות ואינה מנפיקה תעודות אמיתיות, כך שניתן להיכשל שם ללא הגבלה. הריצו את הפקודה האמיתית רק לאחר הצלחה ב-staging. לגבי המכסות האחרות – 50 תעודות לכל מתחם רשום בשבוע, או 5 כפילויות של אותו סט שמות בשבוע – תיתקלו בהן רק אם סקריפט כלשהו מבצע הנפקה בלולאה.

ברגע ש-HTTPS פעיל, זכרו שהתעודה מאבטחת את ה-transport בלבד, לא את השרת: פורט 22 עדיין חשוף לניסיונות ניחוש סיסמה לאורך כל היום. שילוב של הגנה זו עם Fail2ban ב-Ubuntu 24.04 הוא הצעד הטבעי הבא לביצוע ב-30 הדקות הקרובות.

FAQ

האם עליי להתקין את Certbot באמצעות snap או apt עבור Apache ב-Ubuntu 24.04?

השתמשו ב-apt. הגרסה של Ubuntu 24.04 היא Certbot 2.9.0, שהיא עדכנית מספיק עבור כל המפורט במדריך זה, מקבלת עדכוני אבטחה דרך unattended-upgrades, ואינה דורשת את snapd. בחרו ב-snap רק אם אתם זקוקים לגרסה החדשה ביותר באופן מיידי או לתוסף DNS שמופץ בלעדית כ-snap. אם אתם עוברים ל-snap, בצעו תחילה apt remove certbot python3-certbot-apache כדי למנוע מצב שבו שני מתזמני חידוש פועלים במקביל.

מדוע Certbot מציג את השגיאה "Unable to find a virtual host listening on port 80"?

הסיבה היא שאין אף vhost פעיל המאזין לפורט 80 עם ServerName או ServerAlias התואמים לדומיין שהעברתם עם -d. ה-vhost המוגדר כברירת מחדל ב-Ubuntu מגיע עם ServerName כשהוא מוער (commented out). הריצו את sudo apache2ctl -S, מצאו (או צרו) את ה-vhost שאמור להיות אחראי על שם המתחם, הוסיפו את ServerName example.com, טענו מחדש את Apache, והריצו את Certbot שוב.

כיצד אתקן שגיאת "Timeout during connect (likely firewall problem)"?

השירות של Let's Encrypt לא הצליח להגיע לפורט 80 בכתובת שה-DNS שלכם מפרסם. בדקו את ה-firewall ברמת לוח הבקרה של ספק השרת וכן את ufw. ודאו ש-dig +short example.com מחזיר את ה-VPS הנוכחי, ומחקו או תקנו כל רשומת AAAA מיושנת; תהליך האימות מעדיף IPv6 כאשר הוא קיים. אשרו את התיקון מחוץ לשרת באמצעות curl -I http://example.com, ולאחר מכן בצעו הרצה ניסיונית עם sudo certbot certonly --apache --dry-run -d example.com לפני הנפקה אמיתית.

האם Certbot מחדש תעודות באופן אוטומטי ב-Ubuntu 24.04?

כן. חבילת ה-apt מתקינה את certbot.timer, טיימר של systemd שרץ פעמיים ביום ומחדש כל תעודה שנמצאת בטווח של 30 יום לפני פקיעתה, תוך טעינה מחדש של Apache לאחר מכן; גרסת ה-snap משתמשת ב-snap.certbot.renew.timer לאותה מטרה. ודאו זאת עם systemctl list-timers certbot.timer ובצעו הרצה ניסיונית עם sudo certbot renew --dry-run. אל תוסיפו cron job משלכם בנוסף לכך.

כיצד אוכל להנפיק תעודת wildcard עם Certbot ו-Apache?

תעודות wildcard דורשות את אתגר ה-DNS-01: על Certbot להציב רשומת TXT ב-_acme-challenge.example.com, מה שמחייב תוסף certbot-dns-* עם פרטי גישה (API credentials) לספק ה-DNS שלכם (החלופה של --manual דורשת עריכה ידנית של רשומות TXT בכל חידוש). אם יש לכם רק מספר קטן של תת-דומיינים ידועים, תעודת SAN המפרטת אותם במפורש היא פשוטה יותר ושומרת על מפתחות ה-API של ה-DNS מחוץ לשרת.