SSD Nodes Learn Hosting plans →
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-07

יצירת תעודת TLS בחתימה עצמית ב-Ubuntu 24.04

למדו להנפיק תעודת TLS עם SAN שדפדפנים מקבלים ב-Ubuntu 24.04. המדריך כולל פקודת openssl אחת, הגדרת Nginx או Apache, ושיטת עבודה נכונה לביטול אזהרות אבטחה ללא curl -k.

מה אתם בונים

תעודת TLS בחתימה עצמית שדפדפנים ולקוחות מודרניים אכן מקבלים, הגדרות נכונות של subjectAltName, הרשאות קובץ מפתח תקינות, הטמעה בתוך Nginx או Apache, בתוספת החלק שרוב המדריכים מדלגים עליו: לגרום ללקוחות שלכם לבטוח בה כראוי, במקום ללחוץ על אזהרות ולהטמיע curl -k בקוד הסקריפטים לנצח. בסיום, תלמדו להקים רשות אישורים (CA) פרטית בחמש פקודות, למקרה ששירות פנימי אחד יהפוך לשישה.

ראשית, ההחלטה: תעודה בחתימה עצמית היא הכלי הנכון לעיתים רחוקות הרבה יותר ממה שמשתמשים בה. אם השירות נגיש מהאינטרנט הציבורי תחת שם DNS אמיתי, הפסיקו לקרוא והשיגו תעודת Let's Encrypt בחינם עם certbot ב-nginx או החלופה המקבילה ל-Apache. זה לא עולה דבר, מתחדש מעצמו, וכל דפדפן בעולם כבר בוטח בו. תעודה בחתימה עצמית באתר ציבורי מאמנת את המשתמשים שלכם ללחוץ על אזהרות אבטחה, וזה הרגל גרוע יותר משימוש ב-HTTP רגיל.

חתימה עצמית היא הכלי הנכון כאשר אין אינטרנט ציבורי בתמונה: פאנל ניהול המקושר ל-כתובת מנהרת WireGuard ב-VPS שלכם, שרת staging ברשת פרטית, תעבורה בין שירותי backend, מכשיר ב-home-lab, או החלפת תעודת ברירת המחדל ש-Webmin מייצר עבור עצמו בפורט 10000. בכל מקרה, Let's Encrypt לא יכולה להנפיק תעודות עבור 10.8.0.1 או git.internal.lan, ואף רשות אישורים ציבורית לא תכניס כתובת IP פרטית או TLD מומצא לתוך תעודה. עבור שמות אלו, אתם הם ה-CA.

כל מה שמופיע להלן רץ על שרת Ubuntu 24.04 טרי, הכולל את OpenSSL 3.0.x (השתמשו ב-openssl version כדי לוודא). שום דבר כאן לא דורש גישה לאינטרנט; הכל עובד בסביבה מנותקת (air-gapped).

מדוע פקודת השורה האחת הישנה מנפיקה תעודות ש־Chrome דוחה

הפקודה שכל מדריך שנכתב לפני 2017 מציע נראית כך:

# Do not run this — shown so you recognise it in old guides
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout selfsigned.key -out selfsigned.crt

היא מציגה סדרה של שאלות אינטראקטיביות, מציבה את שם המארח (hostname) בשדה ה-Common Name, ומנפיקה תעודה ללא סיומת subjectAltName. תעודה כזו אינה תקינה מרגע יצירתה. דפדפן Chrome הפסיק לקרוא את ה-Common Name בגרסה 58, עוד באפריל 2017. התקן RFC 2818 כבר הוציא משימוש את ההתאמה לפי CN בשנת 2000, ודפדפני Firefox, Safari, וכן הכלים curl ו-Python מתנהגים באותו אופן. תעודה מזהה את השרת שלה אך ורק דרך סיומת ה-SAN, ואם היא חסרה, הדפדפן מציג את ההודעה הבאה:

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is git.internal.lan; its security
certificate does not specify Subject Alternative Names.

שום שינוי ב-trust-store לא יתקן שגיאה זו, כיוון שהתעודה אינה מגדירה שום שם באופן תקני. אם אתם רואים כעת את NET::ERR_CERT_COMMON_NAME_INVALID, סימן שלתעודה שלכם אין SAN (או שהוא שגוי) ועליכם להנפיק תעודה חדשה. למרבה המזל, התיקון מסתכם בפקודה אחת.

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

החל מגרסה 1.1.1, OpenSSL כולל את הדגל -addext, מה שמייתר את הצורך בשימוש בקובצי הגדרה מורכבים כפי שהיה נהוג בעבר כדי להזריק SAN. ב-Ubuntu 24.04:

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 730 -noenc \
  -keyout /etc/ssl/private/git.internal.key \
  -out /etc/ssl/certs/git.internal.crt \
  -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"

מה עושה כל דגל:

  • -x509 מנפיק תעודה חתומה עצמית ישירות, במקום בקשת חתימה (CSR).
  • -newkey rsa:4096 מייצר מפתח חדש באותו שלב. RSA 4096 נתמך בכל הלקוחות הישנים; אם כל הלקוחות המתחברים מודרניים, -newkey ec -pkeyopt ec_paramgen_curve:P-256 קטן ומהיר יותר.
  • -noenc הוא הכתיב של OpenSSL 3.x עבור -nodes הישן: ללא סיסמה (passphrase) למפתח. שני הכתיבים עובדים. מפתח עם סיסמה יגרום ל-nginx להמתין לקלט בכל עליית שרת, לכן עבור מפתח שרת יש להשתמש בדגל זה.
  • -days 730, שנתיים; פירוט נוסף על מספר זה מופיע בסעיף תוקף התעודה.
  • -subj עונה על השאלות האינטראקטיביות באופן מובנה. ה-CN הוא קוסמטי בלבד כיום, אך מומלץ להגדיר אותו לשם הראשי; כלים מסוימים מציגים אותו.
  • -addext "subjectAltName=..." הוא הדגל הקריטי. יש לרשום כל שם וכל כתובת IP שהלקוחות יקלידו: ערכי DNS: עבור שמות מארח (ניתן להשתמש ב-wildcards כמו DNS:*.internal.lan), וערכי IP: עבור כתובות. אם מישהו יגלוש ל-https://10.8.0.1, ערך ה-IP:10.8.0.1 חייב להופיע שם; SAN המכיל רק DNS יגרום להצגת NET::ERR_CERT_COMMON_NAME_INVALID שוב ושוב.

וודאו שה-SAN אכן קיים בתעודה לפני שמחברים אותה לשירות כלשהו:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -ext subjectAltName

פלט תקין:

X509v3 Subject Alternative Name:
    DNS:git.internal.lan, IP Address:10.8.0.1

אם הפלט מציג No extensions in certificate, לתעודה אין SAN ודפדפנים ידחו אותה. יש לייצר אותה מחדש במקום להמשיך הלאה.

אבטחת מפתח פרטי

מפתח פרטי שניתן לקריאה על ידי כל משתמש במערכת אינו מפתח פרטי. ב-Ubuntu, התיקייה /etc/ssl/private כבר מוגדרת כ-710 root:ssl-cert, מה שמונע גישה מזדמנת, אך יש להגדיר את ההרשאות לקובץ עצמו באופן מפורש:

sudo chown root:root /etc/ssl/private/git.internal.key
sudo chmod 600 /etc/ssl/private/git.internal.key

הן nginx והן Apache קוראים תעודות כ-root לפני שהם מורידים הרשאות, לכן מצב root:root של 600 מתאים עבורם. אם המפתח מיועד לשירות שרץ תחת משתמש ייעודי וטוען את המפתח בעצמו, כגון יישום Node, Gitea או daemon של Python, יש לבצע chown למשתמש השירות הרלוונטי, תוך שמירה על מצב 600. מה שאסור לעשות לעולם: הגדרת מצב 644, שמירת עותק במאגר git, או שמירת עותק ב-/tmp.

חיבור לתוך nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.internal.lan;

    ssl_certificate     /etc/ssl/certs/git.internal.crt;
    ssl_certificate_key /etc/ssl/private/git.internal.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}
sudo nginx -t && sudo systemctl reload nginx

nginx -t חייב להדפיס syntax is ok וגם test is successful לפני שהטעינה מחדש (reload) מבצעת פעולה כלשהי. אם במקום זאת מודפס SSL_CTX_use_PrivateKey_file() failed ... key values mismatch, סימן שהתעודה והמפתח נוצרו בשני תהליכי יצירה שונים; עיינו בסעיף מצבי הכשל (failure-modes).

חיבור ל-Apache

sudo a2enmod ssl proxy proxy_http

ssl לבדו אינו מספיק כאן: ה-vhost להלן משתמש ב-ProxyPass, ובלי mod_proxy ו-mod_proxy_http בדיקת התצורה תיכשל עם Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration. שמרו את ה-vhost כ-/etc/apache2/sites-available/git-internal.conf:

<VirtualHost *:443>
    ServerName git.internal.lan
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/git.internal.crt
    SSLCertificateKeyFile   /etc/ssl/private/git.internal.key

    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>
sudo a2ensite git-internal
sudo apache2ctl configtest && sudo systemctl reload apache2

configtest אמור להשיב Syntax OK. כעת בצעו בדיקה ממכונת לקוח:

curl -v https://git.internal.lan/

ותקבלו שגיאה:

curl: (60) SSL certificate problem: self-signed certificate

זה אינו באג. זהו TLS בפעולה: curl לא מכיר את התעודה שלכם ומסרב לתקשר עם שרת שהוא אינו יכול לאמת. הסעיף הבא הוא הפתרון האמיתי, והוא אינו מה שחצי מהאינטרנט עושה ברגע זה ממש.

גרימת אמון מצד לקוחות, ודפוסי פעולה שגויים שיש להימנע מהם

תחילה, התיקונים השגויים, כפי שהם באמת. curl -k (או --insecure) שמוטמעים בתוך סקריפט, verify=False בתוך בקשות Python, או NODE_TLS_REJECT_UNAUTHORIZED=0 בתוך Node, אינם הופכים את התעודה שלכם למהימנה. הם פשוט מכבים את אימות התעודה, מה שאומר שהלקוח יתקשר בשמחה לכל שרת שיציג כל תעודה שהיא, כולל תעודה שנתקפה על ידי גורם עוין בדרך. אתם נשארים עם התקורה של TLS ומאבדים את האימות שהיה כל מטרתו. גרוע מכך, הדגלים הללו מתפשטים: הם מודבקים לתוך משימת cron, משם לסקריפט פריסה, ולבסוף לקוד הייצור, עד שאף אחד לא זוכר אילו חיבורים היו אמורים להיות זמניים בלבד. אם verify=False שורד מעבר לסשן הניפוי (debugging) שיצר אותו, סימן שהתכנון שגוי.

התיקון הנכון הוא ללמד כל מערכת הפעלה של לקוח שהתעודה הזו היא שורש מהימן. בלקוחות Ubuntu ו-Debian:

sudo cp git.internal.crt /usr/local/share/ca-certificates/git.internal.crt
sudo update-ca-certificates

השורה החשובה בפלט (בלוק Running hooks in /etc/ca-certificates/update.d... מופיע אחריה):

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

שני מכשולים חבויים בשורות אלו. הקובץ חייב להסתיים ב-.crt, סיומת .pem מתעלמת בשקט מהקובץ ואתם מקבלים 0 added ללא הודעת שגיאה. כמו כן, התוכן חייב להיות בפורמט PEM, הקובץ מתחיל ב------BEGIN CERTIFICATE-----; המירו קובץ בינארי בפורמט DER תחילה באמצעות openssl x509 -inform der -in file.der -out file.crt. הוספת התעודה החתומה עצמית כשורש עובדת מכיוון שתעודה חתומה עצמית היא השורש של עצמה.

לאחר מכן, curl, wget, git, apt, וכל כלי אחר שמשתמש ב-OpenSSL מול מאגר המערכת, יבטחו בשרת ללא צורך בדגלים כלל. מספר מצומצם של לקוחות מחזיקים מאגרי אמון משלהם וזקוקים לטיפול פרטני:

  • Chrome/Chromium ב-Linux קורא מסד נתונים מסוג NSS, לא את מאגר המערכת: sudo apt install libnss3-tools, ולאחר מכן certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt לכל משתמש.
  • ל-Firefox יש מאגר משלו: הגדרות → פרטיות ואבטחה → תעודות → ייבוא, או שנו את security.enterprise_roots.enabled ל-true בתוך about:config כדי שיקרא את מאגר המערכת.
  • Python requests מגיע עם מאגר CA משלו (certifi) ומתעלם ממאגר המערכת: העבירו את verify="/usr/local/share/ca-certificates/git.internal.crt" או בצעו export ל-REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt.
  • Node.js: בצעו export ל-NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt.

בלקוחות Windows, לחצו פעמיים על ה-.crt והתקינו אותו תחת Trusted Root Certification Authorities; ב-macOS, הוסיפו אותו ל-System keychain בתוך Keychain Access וסמנו אותו כ-Always Trust.

שורש אחד עבור שירותים רבים: רשות אישורים (CA) פרטית קטנה

ניהול אמון עבור כל תעודה בנפרד מפסיק להיות יעיל ברגע שהמערכת גדלה: שישה שירותים כפול ארבע מכונות לקוח שווים עשרים וארבע התקנות אמון, וכל שירות חדש מוסיף עוד. הפתרון הוא רשות אישורים (CA) פרטית; הלקוחות נותנים אמון בשורש אחד, ואתם חותמים באמצעותו על התעודה של כל שירות.

האפשרות הנוחה היא mkcert, שנמצאת במאגרים של Ubuntu 24.04 ומטפלת במאגרי NSS (של Chrome ו-Firefox) ש-update-ca-certificates מפספס:

sudo apt install -y mkcert libnss3-tools
mkcert -install
mkcert git.internal.lan "*.internal.lan" 10.8.0.1

mkcert -install יוצר שורש ורושם אותו בכל מאגר אמון באותה מכונה; הפקודה השלישית מפיקה את git.internal.lan+2.pem ואת git.internal.lan+2-key.pem, שמוכנים להטמעה בקטעי הקוד של nginx או Apache שהוצגו לעיל. הנחת העבודה של הכלי היא סביבת פיתוח, ומפתח השורש נשמר על המכונה שבה הורץ -install, לכן הוא מושלם למחשב פיתוח אך אינו מתאים לצי שרתים.

עבור שרתים, OpenSSL רגיל מבצע את כל תהליך ה-CA בחמש פקודות:

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -key lab-ca.key -sha256 -days 3650 \
  -out lab-ca.crt -subj "/CN=Lab Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genrsa -out git.key 2048
openssl req -new -key git.key -out git.csr -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"
openssl x509 -req -in git.csr -CA lab-ca.crt -CAkey lab-ca.key \
  -CAcreateserial -days 730 -sha256 -copy_extensions copy -out git.crt

המלכוד נמצא בפקודה האחרונה: openssl x509 -req מסיר כברירת מחדל את כל התוספים מתוך ה-CSR, כולל ה-SAN שהוספתם בקפידה. -copy_extensions copy (אפשרות ב-OpenSSL 3.x, לכן היא עובדת ב-24.04) מעביר אותם הלאה; אם תשמיטו אותו, התעודה החתומה תהיה ללא SAN, ו-Chrome יקבל את פניכם שוב עם NET::ERR_CERT_COMMON_NAME_INVALID. ודאו זאת באמצעות אותה בדיקת openssl x509 -noout -ext subjectAltName כמו קודם.

הפיצו את lab-ca.crt ללקוחות באמצעות שלבי מאגר האמון לעיל, פעם אחת לכל מכונה, וזהו. שמרו על lab-ca.key כמו על אוצר לאומי: הרשאות 600, ועדיף להחזיקו במכונה שאינה אחד השרתים שעבורם הוא חותם, שכן מי שמחזיק בו יכול להנפיק תעודה לכל שם שהלקוחות שלכם יסמכו עליו.

תוקף ורענון תעודות

משך החיים של תעודות מ־Public CA הולך ומתקצר. פורום ה־CA/Browser הגביל את תוקפן של תעודות חדשות המהימנות לציבור ל-200 ימים החל ממרץ 2026 (ירידה מ-398), עם צמצום נוסף ל-100 ימים ב-2027 ו-47 ימים עד מרץ 2029. עם זאת, כללים אלו מחייבים רק רשויות אישור (CAs) המהימנות לציבור. ה-CA הפרטי שלכם אינו כפוף להם, ודפדפנים אינם אוכפים מגבלות אלו על שורשים (roots) שהותקנו ידנית. מגבלה אחת מהעולם האמיתי אכן חלה: פלטפורמות Apple דוחות כל תעודת שרת TLS שתוקפה עולה על 825 ימים, ללא קשר לזהות המנפיק. לכן, אם צפויים חיבורים ממכשירי iPhone או מחשבי Mac, הקפידו שתוקף תעודות ה-leaf לא יעלה על שנתיים. -days 730 עומד ברף זה בכל מקום; תעודת root ל-10 שנים עם תעודות leaf לשנתיים היא תצורה פנימית נוחה.

תעודות בעלות אורך חיים רב נכשלות בדרך אחת בלבד: בשקט, בבת אחת, בתאריך שאף אחד לא זוכר שבחר. בדקו מה ברשותכם:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -enddate

רשמו את מועד החידוש ביומן עבודה, או הגדירו משימת cron שתתריע לכם 30 ימים מראש. הפקודה openssl x509 -checkend 2592000 -in cert.crt מסתיימת עם קוד שגיאה (non-zero) ברגע שהתוקף קרוב יותר ממספר השניות שצוין. אם אתם כבר מריצים את Uptime Kuma לניטור מצב, צגי ה-HTTPS שלו יתריעו בחינם על תעודות שתוקפן עומד לפוג.

רענון תעודות מול CA פרטי הוא תהליך משעמם ופשוט: הריצו מחדש את פקודות ה-CSR והחתימה, החליפו את הקבצים וטענו מחדש את שרת האינטרנט. ה-root לא השתנה, לכן אף לקוח לא יבחין בשינוי.

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

NET::ERR_CERT_AUTHORITY_INVALID, זהו המצב הצפוי לפני התקנת אמון, ואין מדובר בפגם בתעודה. אם השגיאה נמשכת לאחר התקנת ה-root: בלינוקס, Chrome קורא מ-NSS ולא ממאגר המערכת (ראו את שלב certutil); או שהקובץ שהועתק לא הסתיים ב-.crt ו-update-ca-certificates הציג 0 added; או שהשרת מציג תעודה שונה מזו שביקשתם לבטוח בה – השוו את ה-fingerprints באמצעות openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256.

NET::ERR_CERT_COMMON_NAME_INVALID, לתעודה אין SAN, או שה-SAN אינו מכסה את השם בשורת הכתובת. המקרה הקלאסי: ה-SAN מפרט את DNS:git.internal.lan אך המשתמש גלש ל-https://10.8.0.1. שינויים במאגר האמון לא יפתרו זאת; יש להנפיק מחדש את התעודה עם הערך החסר.

curl: (60) SSL certificate problem: self-signed certificate, השירות curl אינו בוטח בתעודה. הווריאציה self-signed certificate in certificate chain מציינת את אותה הבעיה עבור תעודה שנחתמה על ידי ה-CA הפרטי שלכם. פתרון חד-פעמי: curl --cacert lab-ca.crt https://...; פתרון קבוע: עדכון מאגר האמון. לא -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (או Expecting: CERTIFICATE REQUEST, או no start line), בלבול בפורמט PEM. הזנתם ל-OpenSSL סוג קובץ שגוי: מפתח או CSR במקום תעודה, או קובץ בינארי בפורמט DER במקום PEM. הפקודה head -1 filename תציג לכם מהו הקובץ שבידיכם; תעודה מתחילה ב------BEGIN CERTIFICATE-----. עבור DER, בצעו המרה באמצעות openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch), התעודה והמפתח אינם שייכים זה לזה. לרוב זה קורה כי פקודת ההנפקה הורצה פעמיים והקבצים התערבבו. אשרו זאת באמצעות השוואת openssl x509 -in git.internal.crt -noout -pubkey | sha256sum מול openssl pkey -in git.internal.key -pubout | sha256sum; ערכי hash זהים מעידים על זוג תואם. אם הם שונים, הנפיקו את שניהם מחדש כזוג.

FAQ

מדוע Chrome עדיין מציג "Not secure" לאחר שיצרתי תעודה בחתימה עצמית?

אם השגיאה היא NET::ERR_CERT_AUTHORITY_INVALID, התעודה תקינה, אך ל-Chrome אין עדיין סיבה לתת בה אמון. התקינו אותה (או את ה-root של ה-CA הפרטי שלכם) במאגר האמון של הלקוח, וזכרו שב-Linux, ‏Chrome משתמש ב-NSS database דרך certutil, ולא במאגר המערכת. אם השגיאה היא NET::ERR_CERT_COMMON_NAME_INVALID, חסר בתעודה Subject Alternative Name התואם ל-URL, ויש להנפיק אותה מחדש עם -addext "subjectAltName=...".

כיצד אוכל לגרום ל-curl לתת אמון בתעודה בחתימה עצמית ללא השימוש ב-curl --cacert /path/to/cert.crt?

העתיקו את התעודה (בפורמט PEM, סיומת .crt) לתוך /usr/local/share/ca-certificates/ והריצו את sudo update-ca-certificates; הפלט חייב לציין 1 added. מרגע זה, curl יאמת אותה כמו כל תעודה ציבורית. עבור בקשה חד-פעמית ללא שינוי במערכת, curl --cacert /path/to/cert.crt יבצע אימות מול הקובץ הזה בלבד; -k מבטל את האימות לחלוטין ואין להשתמש בו בסקריפטים.

לכמה זמן יכולה תעודה בחתימה עצמית להיות בתוקף?

טכנית, לכל זמן שתבחרו; המגבלות של ה-CA/Browser Forum (כיום 200 ימים, 47 ימים עד שנת 2029) מחייבות רשויות אישור ציבוריות, לא אמון פרטי. בפועל, הגבילו תעודות שרת ל-825 ימים, כיוון שמכשירי Apple דוחים כל תעודה ארוכה יותר ללא קשר למנפיק. root פרטי לעשר שנים עם תעודות קצה לשנתיים (-days 730) הוא ברירת מחדל סבירה; פשוט תזמנו את החידוש ביומן, כיוון שתעודה פנימית שפג תוקפה משביתה את הכל בשקט בתאריך שאף אחד לא זוכר.

האם עלי להשתמש בתעודה בחתימה עצמית או ב-Let's Encrypt?

אם לשירות יש שם DNS ציבורי והוא נגיש מהאינטרנט, השתמשו תמיד ב-Let's Encrypt; זה חינמי, אוטומטי, וזוכה לאמון מכל לקוח. תעודה בחתימה עצמית (או CA פרטי) מיועדת למקרים שבהם Let's Encrypt לא יכולה להנפיק תעודה: כתובות IP פרטיות, שמות מארח פנימיים כמו .lan, רשתות מנותקות (air-gapped), ושירותים שמוסתרים בכוונה מאחורי VPN. ההחלטה נוגעת לנגישות ולמתן שמות, לא לעוצמת האבטחה; הקריפטוגרפיה זהה.

מדוע התעודה שלי נדחית גם לאחר שהוספתי אותה ל-/usr/local/share/ca-certificates?

בדקו שלושה דברים. הקובץ חייב להסתיים ב-.crt, סיומת .pem תגרום להתעלמות שקטה והפקודה update-ca-certificates תדווח על 0 added. התוכן חייב להיות טקסט PEM המתחיל ב------BEGIN CERTIFICATE-----, ולא קובץ בינארי בפורמט DER. כמו כן, היישום חייב להשתמש בפועל במאגר המערכת; Chrome ב-Linux, ‏Firefox, ‏Python requests, ‏Node.js ו-Java מחזיקים כל אחד מאגר אמון פרטי ודורשים הוספה נפרדת של התעודה.

#openssl#tls#self-signed#ubuntu#security