תעודות TLS וחידוש אוטומטי

למה אתה צריך את זה?

TLS מצפין את התנועה ”kliyent↔servis”, מאשר את האותנטיות של השרת (ועם mTLS - לקוח), וגם מגן מפני זיוף. הסיכונים העיקריים: עיכובי תעודה, מפתחות חלשים, שרשרת אמון שגויה, נהלים ידניים. מטרת המאמר היא לתאר את הארכיטקטורה שבה תעודות תמיד רלוונטיות וסיבובים עוברים מבלי שיבחינו בהם המשתמשים.

מושגים בסיסיים

CA/Signatory: סמכות הסמכה (ציבורית או פנימית).
שרשרת (fulchain): תעודת עלה + intermediate + root (בדרך כלל שורש במאגרי הלקוח).
רשימת תחומים/IP לתעודה אחת (multi-SAN).
ווילד קארד: ". חיקוי. com - נוח עבור תת-דומים רבים, דורש אימות DNS.
הידוק OCSP: השרת תקף את מצב שלילת המיקום האחרון; מפחית את האיחור והתלות במחלות OCSP חיצוניות.
HPKP: מיושן/לא בשימוש; במקום זאת, יומני CT והיגיינת מפתח.
CT (שקיפות תעודה): יומני ההנפקה לציבור - חשובים לשליטה בשחרורים מזויפים.

פרופיל ומפתחות קריפטו

• ECDSA (P-256) - מהיר וקומפקטי; העדיפו לקוחות מודרניים.
• RSA-2048/3072 - עדיין תואם; ניתן להחזיק dual-cert (RSA + ECDSA).
• דור מפתח: רק בצד המטרה (לא להעביר פריבטירים מעל הרשת), להגן על זכויות הגישה ('0600').
• HSM/KMS: עבור אזורים קריטיים (תשלום/PII) לאחסן מפתחות ב HSM/KMS, לאפשר פעולות ביקורת.
• תקופות חיים: תעודות קצרות (90 יום/30 יום לבדיקה פנימית) מעודדות סיבוב תדיר ומפחיתות את הסיכון לפשרה.

מודלים ארכיטקטוניים של ניהול TLS

1. CA ציבורי באמצעות ACME (בואו להצפין/Buypass/וכו ')

אימות: HTTP-01 (באמצעות שרת אינטרנט/Ingress) או DNS-01 (עבור domains wild/out-of-stream).
מקצוענים: חופשי/אוטומטי, אמון רחב. אסירים: תלויות חיצוניות.

2. חוקרת תאגידים פנימיים

כלים: HashiCorp Vault PKI, Smallstep (Step-ca), Microsoft AD CS, CFSSL.
מקצוענים: מדיניות מותאמת אישית, mTLS, TTL קצר, שחרור עבור תחומים פנימיים. הפצת שורש, ניהול אמון.

3. היברידי

CA ציבורי למשתמשים חיצוניים; Internal CA - לשירות (MTLS), ערוצים בין-אשכולות ומנהלים.

תבניות חידוש אוטומטי (חידוש)

עקרונות כלליים

סף חידוש: להתחיל ב ”יומן 30” ימים לפני תפוגה; לשירותים קריטיים ביום 45.
זמן אפס: הנפקת תעודה חדשה, החלפה אטומית, טעינה חלקה בלי לשבור חיבורים.
אחיזה כפולה (כחול/ירוק): לאחסן את הסלט הנוכחי הבא; מתחלף - באמצעות סימלינק או סוד מרומז.
התראה: 45/30/14/7/3/1 אזהרות יום; התראה נפרדת במהלך כישלון אתגר ACME.

לקוחות ACME ויישומם

סרטבוט/אקמי. sh/lego: סוכנים קלים על VM/חשוף-מתכת.
מנהל (Kubernetes): מפעיל עובד עם Issuer/Clought Issuer; משחרר/מחדש אוטומטית וכותב לסוד.
שלב-ca/Cault סוכן: שחרור אוטומטי/סיבוב עם TTL קצר, דפוסי סירה לעדכון מפתחות ושרשראות.

תהליכים עבור קוברנטס

yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx

yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней

החלפה חמה ב NGINX-Ingress מתרחשת באופן אוטומטי כאשר ”סוד” מעודכן. הוסף 'sl-ecdh-curve: secp256r1' ואפשר הידוק OCSP באמצעות/הגדרות Map.

תהליכים עבור VM/Bare-metal

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

תקופתי ”certbot לחדש” באמצעות טיימר מערכת.
עבור כרטיס בר, השתמש DNS-01 (ספק תוספים) ודומה ל - decploy-wook.

bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"

החלפה אטומית NGINX

שמור 'fulchain. Pem 'privkey. pem 'תחת נתיבים יציבים (symlink לקבצים versied), ואז' nginx's reload's.

Internal PKI ו-mTLS

bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256

שחרור אוטומטי: באמצעות סוכן כספת (K8s) או סירה; הבקשה קוראת מחדש את הסלט מקובץ הצופה/FS.
שורט TTL: 24-720 שעות, אשר מעודד סיבוב תדיר ומפחית את הערך של המפתח הגנוב.
MTLS: הנפקת תעודות לקוח עבור שירותים/תפקידים ספציפיים; בקלט - TLS הדדי בחדירה/sidecar-proxy.

מבצע בטוח

שיתוף סודות: מפתחות פרטיים - רק על המארח/תרמיל, גישה לפי העיקרון של הכי פחות זכויות.
זכויות קובץ: '600' עבור מפתח; בעלים - משתמש תהליך.
תקופת חסד: הגדר 'מחדש לפני' כדי להיות מספיק כדי להסביר כשלים DNS/ACME/ספק.
הידוק OCSP: להדליק בחזיתות; לפקח על הרעננות של התגובה (בדרך כלל 12-72 שעות).
HSTS: להדליק בהדרגה (ללא ”טעינה מראש” בהתחלה), לוודא את מסירת HTTPS הנכונה של כל התוכן.
Dual-Cert (RSA + ECDSA): משפר את התאימות והביצועים; תן ECDSA ללקוחות מודרניים.

ניטור ו SLO

• ימים לפני התפוגה (מד) לכל תחום/סוד; SLO: ”אין סלט מ <7 ימים לפקיעה”.
• תקפות שרשרת (linting), ציות SAN עם התחומים הנדרשים/IP.
• מצב הידוק OCSP (רעננות התגובה).
• אחוז האתגרים המוצלחים/לא מוצלחים ACME.
• לחיצות ידיים של Leitency TLS, גרסאות פרוטוקול/צפנים (ביקורת חשבונות).

• התראה: 30 ימים עד תפוגה.
• קריט: 7 ימים/כישלון ”לחדש”.
• עמוד: 72 שעות/שרשרת לא תקפה בהידוק ה ־ OCSP.

תקריות וגלגולים

עיכוב תעודה: הוצאה זמנית ופריסה ידנית, תיקון RCA (מדוע חידוש לא עבד, חסימת DNS/API).
פשרת מפתח: ביטול מיידי, סיבוב סודות, ביקורת גישה, סיבוב של אסימוני חשבון DNS/ACME.
שרשרת שגויה: הפקדה דחופה של 'fullchain' הנכון, עומס מחדש מאולץ של חזיתות.
נעילה לספק DNS: שמור על נתיב אימות הגיבוי (HTTP-01) או DNS משני.

רשימת יישום חידוש אוטומטי

1. בחר את המודל (CA ציבורי באמצעות ACME/internal PKI/hybrid).
2. הגדר את פרופיל ההצפנה: ECDSA-P256, במידת הצורך כפול-סלט עם RSA-2048.
3. הגדרת הסוכן האוטומטי (סרט-מנהל, certbot, acme. SH, סוכן כספת).
4. ארגן החלפת אפס-הורדה (תבנית סימלינק, כניסה/NGINX/שליח).
5. הפעל הידוק OCSP ו ־ HSTS (בשלבים).
6. הוספת תאריכי התראה ואתגר מדינות; מרשם SLO.
7. לתעד את שברי הזכוכית ותהליכי שחרור ידניים.
8. ביצוע תרגילים ”מזויפים”: DNS-01 שבור, נפילת ACME, פג תוקפו של שורש/ביניים.
9. סקור גישה למפתחות פרטיים, סובב אסימונים לספקי DNS וחשבונות ACME.

תכונות עבור iGaming/fintech

PCI DSS/PII: סוויטות צופן קפדניות, נאלץ TLS 1. 2+/1. 3, לכבות צפנים חלשים/דחיסה, חידוש מפגש ללא פשרות אבטחה.
מקטע דומיין: תעודות נפרדות לתשלום תת-דומיין ומנהל; לספקי תוכן - שרשראות מבודדות.
ביקורת ורישום: שחרור תקליט/החזר/סיבוב; חתום על חפצי סי-אי-סי-די.
ריבוי תחומים: איסורים מקומיים לאזורים כדי לא להיות תלויים בכישלונות חוצים-אזוריים.

תצורות מדגם

NGINX (RSA + ECDSA, הידוק OCSP)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;

ssl_certificate   /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate   /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000" always;

OpenSSL: CSR (ECDSA-P256)

bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"

CFSSL: פרופיל והוצאה לאור

json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}

bash cfssl gencert -profile=server ca. json csr. json      cfssljson -bare server

FAQ

אני צריך כרטיס בר?
אם תת-סמים חדשים מופיעים לעיתים קרובות, כן (באמצעות DNS-01). אחרת, תשתמש ברב-סאן לתחומים מפורשים.

מה לבחור: מנהל הסריטה או סרטבוט?
Kubernetes # cert-manager. VM/microservices מתוך K8s certbot/lego/acme. sh. PKI Internal * כספת/צעד-ca.

האם ניתן לצמצם את הטי-טי-אל ליום אחד?
עבור mTLS פנימי, כן, אם אוטומציה/סירה מבטיחה סיבוב ויישומים יכולים לטעון מחדש.

איך לאבטח את DNS-01?
גישה סמלית/מינימלית נפרדת לאזור, סיבוב מפתח, הגבלת גישה ל-IP API, ביקורת.

סך הכל

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