CA — นายอำเภอที่ลงนาม#

หน้าที่หลักของ CA:

• ออก cert (sign ด้วย private key ของตัวเอง)
• revoke cert เมื่อ cert ถูก compromise / หมดความจำเป็น
• publish CRL / OCSP response ให้วงการเช็คได้ตลอด
• เก็บ private key ของ CA ใน HSM offline ให้ปลอดภัยที่สุด

CA = trust authority + key signer เป็น single source of truth ของทั้งระบบ

RA — เคาน์เตอร์ลงทะเบียนที่ตรวจตัวตน#

หน้าที่ของ RA คือ verify identity ของผู้ขอ cert ก่อนส่งให้ CA sign เช่น:

• ผู้ขอ cert ของ mybank.com ส่ง CSR มา → RA ต้อง verify ว่าผู้ขอครอบครอง mybank.com จริง (DV / OV / EV ที่จะลงในหัวข้อ lifecycle)
• ผู้ขอ cert ของพนักงานบริษัท → RA ต้อง verify ว่าพนักงานคนนี้ทำงานในบริษัทจริง + ระดับสิทธิ์ตรงกับที่ขอ

ทำไมต้องแยก RA ออกจาก CA? = separation of concerns เดียวกับ EP.16:

• คนที่ verify identity (RA) ≠ คนที่ถือ private key signing (CA)
• ถ้า RA โดน compromise → ออก cert ผิดได้ระยะหนึ่ง แต่ private key ของ CA ยังปลอดภัย
• ถ้า CA โดน compromise → catastrophic ออก cert ปลอมได้ทุกอย่าง (เคส DigiNotar)

ในบริษัทขนาดกลางบ่อยครั้ง RA + CA = ทีมเดียวกัน (cost savings) ในวงการที่ critical จะ strict separation RA ทีมหนึ่ง CA ทีมหนึ่ง access ต่างกัน

Repository — ระบบ public ที่ทุกคนเช็คได้#

Repository = public directory ที่ store + distribute:

• cert ทั้งหมดที่ออกแล้ว (เพื่อให้ใครก็ download มาใช้ได้)
• CRL ล่าสุด (ที่จะลงในหัวข้อ revocation)
• OCSP responder URL (endpoint ที่ browser ใช้ถามสถานะ)

Repository มักใช้ protocol อย่าง LDAP, HTTP, หรือ X.500 directory URL ของ Repository ฝังอยู่ในทุก cert (field ชื่อ CRL Distribution Points + Authority Information Access) browser อ่านแล้วรู้ทันทีว่าจะไปเช็คที่ไหน

ทำไม Repository สำคัญ? ลองนึกครับ ถ้า Repository ของ CA ใหญ่ๆ ล่มหรือถูก compromise:

• browser download CRL เก่า → cert ที่ revoke ไปเมื่อวานยังถูกเชื่อ
• โจรที่มี cert ที่ revoke แล้ว → ยังใช้ได้ต่อ
• ไม่มี cert ใหม่ออกได้ระหว่าง Repository ล่ม → outage ทั้ง pipeline

Repository = availability point ที่หลายคนลืมว่าเป็นจุดเปราะของระบบ CA ใหญ่อย่าง DigiCert / Sectigo / Let’s Encrypt ใช้ CDN อย่าง Cloudflare / Akamai distribute Repository หลายร้อย edge ทั่วโลก เพื่อให้ down ทั้งระบบเป็นไปไม่ได้

มุมผู้บริหาร: ถ้าบริษัทคุณตั้ง internal CA เอง ขอ design ให้ครบ 3 ส่วนครับ หลายบริษัทตั้งแค่ CA แล้วใช้ทุกอย่างในเครื่องเดียว verify identity + sign cert + serve CRL ทั้งหมดอยู่ใน server เดียว ถ้าเครื่องนั้น compromise → ทั้งระบบล่ม + ไม่มีทางตรวจสอบย้อนหลังว่าใครออก cert อะไรไป pattern ที่วงการแนะนำคือ RA ทีมหนึ่ง access ระบบ identity (เช่น LDAP / AD), CA เก็บ private key ใน HSM offline, Repository run ในเครื่อง public-facing ที่ replicate หลาย region

ทำไมต้องมี Intermediate — ทำไม Root ไม่ออก leaf cert ตรงๆ?#

คำถามดีครับ. คำตอบคือ — Root CA = single point of catastrophic failure

ลองนึกสถานการณ์ที่ private key ของ Root CA หลุดออกไป. โจรที่ได้ key ของ Root จะ:

• ออก cert ปลอม ให้เว็บไหนก็ได้ในโลก ทุก browser ยอมเชื่อ
• หลอกคนทั้ง internet ให้ login เข้าเว็บปลอม โดยที่ browser โชว์รูปกุญแจสีเขียว
• ไม่มีทางเรียก Root cert กลับ เพราะ Root อยู่ใน trust store ของทุก browser ที่ install ไปแล้วทั่วโลก

ผลคือ ถ้า Root พัง = อินเทอร์เน็ตทั้งระบบที่ใช้ CA นี้พังตามทันที

ทางออกของวงการคือ Root CA ห้ามใช้ออก leaf cert โดยตรง. แทนที่จะใช้ Root จะ offline ส่วนใหญ่ของเวลา. เก็บไว้ใน Hardware Security Module (HSM) ที่ตู้เซฟใต้ดิน + ห้องที่ใช้ biometric เข้า + มีคนเฝ้า 24/7. ใช้แค่ปีละครั้ง เพื่อ sign Intermediate CA cert

Intermediate CA = expendable ถ้าโดน compromise → revoke ตัว Intermediate แล้วออกตัวใหม่ Root ยังปลอดภัย ระบบยังอยู่. นี่คือหลักการ “แบ่งความเสี่ยง” เหมือนกับ Defense in Depth ใน EP.04

ลองนึกในโลกจริง — ราชวงศ์ ไม่ออกบัตรประชาชนให้ประชาชนเอง. ราชวงศ์แต่งตั้ง ขุนนาง ที่มีหน้าที่ออกบัตร. ถ้าขุนนางคนหนึ่งโกง → ปลด → แต่งตั้งคนใหม่ — ราชวงศ์ไม่กระทบ

Cross-signing — ขุนนางที่มีตราจากหลายราชวงศ์#

อีก concept ที่ใช้บ่อยในวงการคือ cross-signing. Intermediate CA สามารถถูก sign โดย Root หลายตัว ได้

ตัวอย่างที่จริงที่สุดในวงการ — Let’s Encrypt. ตอนแรก Let’s Encrypt มี Root ของตัวเองชื่อ ISRG Root X1. แต่ Root ใหม่นี้ไม่ได้อยู่ใน trust store ของ browser เก่า / มือถือเก่า. ถ้าใช้ ISRG Root X1 ตรงๆ → คนใช้ browser เก่าจะเห็น “Untrusted”

Let’s Encrypt เลยขอให้ Root เก่าที่ทุก browser เชื่ออยู่แล้วชื่อ IdenTrust DST Root CA X3 มา cross-sign Intermediate ของตัวเอง. ผลคือ browser ที่ไม่รู้จัก ISRG Root X1 จะ follow chain ขึ้นไปจนเจอ DST Root X3 แล้วเชื่อได้

มุมผู้บริหาร: ลำดับชั้น Root → Intermediate → Leaf ใน PKI = หลักการเดียวกับ Separation of Duties ใน EP.16 คนที่ทำหน้าที่สำคัญที่สุด (Root) ไม่ทำงาน routine เอง มอบหมายให้ Intermediate ถ้า Intermediate ทำพลาด ระบบไม่ล่ม ถ้าบริษัทคุณมี internal CA (ของบริษัท ใช้ออก cert ภายใน) ขอให้ตรวจว่า Root CA ของคุณ offline ไหม + เก็บใน HSM ไหม + มี audit trail ตอนใช้ไหม pattern ของวงการที่เจอบ่อย — บริษัทตั้ง CA ของตัวเองแล้วเก็บ private key ของ Root ในเครื่อง server ที่เปิด 24/7 + ไม่มี HSM + ไม่มี audit log = ระเบิดเวลาที่รอจุด

Subject — บัตรนี้เป็นของใคร#

Subject คือ “เจ้าของบัตร” — บอกว่า cert ใบนี้เป็นของใคร / เว็บไซต์ไหน. ใน cert ของ mail.google.com field นี้จะมี:

• CN (Common Name) = mail.google.com (ชื่อหลักของเว็บ)
• O (Organization) = Google LLC
• L (Locality) = Mountain View
• ST (State) = California
• C (Country) = US

Issuer — ใครเป็นคนออกบัตรนี้#

Issuer คือ “ขุนนางที่ออกบัตรให้”. ใน cert ของ mail.google.com Issuer คือ GTS CA 1C3 (Intermediate ของ Google).

browser ใช้ field นี้เป็น link ไป cert ของชั้นถัดไป — เพื่อ verify chain ขึ้นไปจนเจอ Root

Validity — บัตรนี้ใช้ได้เมื่อไหร่ถึงเมื่อไหร่#

ทุก cert มี Not Before (วันเริ่มใช้ได้) + Not After (วันหมดอายุ). browser ปฏิเสธ cert ที่หมดอายุ หรือ cert ที่ยังไม่ถึงวันใช้

ในปี 2024 วงการบังคับให้ leaf cert ของเว็บไซต์มีอายุไม่เกิน 398 วัน (~13 เดือน). ก่อนหน้านี้เคยมี cert อายุ 10 ปี แต่วงการตัดลงเรื่อยๆ เพราะ:

• ถ้า private key หลุด short-lived cert จำกัดความเสียหายให้สั้น
• บังคับ automation ใครต่ออายุไม่เป็น = ไม่ควรมี cert
• ในปี 2026 Google ผลักให้ลดเหลือ 47 วัน (ยังเป็น proposal แต่ทิศทางชัดเจน)

Public Key — กุญแจ public ของเจ้าของบัตร#

นี่คือ หัวใจ ของ cert. field นี้บรรจุ public key ของ Subject ที่ EP.21 พูดถึง — พร้อมบอกว่าเป็น algorithm อะไร (RSA 2048-bit / ECC P-256 / ECC P-384)

browser ใช้ public key นี้:

• encrypt ข้อความที่จะส่งให้ server (ใน TLS handshake รุ่นเก่า)
• verify signature ที่ server ส่งมา (ใน TLS handshake รุ่นใหม่ TLS 1.3)

Signature — ตราประทับของ Issuer#

ส่วนสุดท้ายที่สำคัญที่สุด — Signature ของ Issuer. Issuer (Intermediate CA) เอาทุก field ข้างบนนี้ — มา hash (EP.22) — แล้ว sign ด้วย private key ของ Intermediate

browser ที่ได้ cert มา จะ:

1. เอาทุก field มา hash ใหม่
2. ใช้ public key ของ Issuer (ใน cert ของ Intermediate) verify signature
3. ถ้าตรง → cert ใบนี้ออกโดย Intermediate จริง — ไม่ถูกแก้กลางทาง

นี่คือจุดที่ Hashing (EP.22) + Asymmetric (EP.21) มาทำงานร่วมกัน. ลายนิ้วมือ + ลายเซ็น = ตราประทับที่ปลอมไม่ได้

SAN (Subject Alternative Names) — เว็บอื่นที่ใช้บัตรเดียวกันได้#

field ที่ สำคัญที่สุดในยุคปัจจุบัน — ที่หลายคนยังไม่รู้ — SAN (Subject Alternative Names)

ยุคก่อน — cert ใช้แค่ CN เพื่อบอกว่า cert นี้ใช้กับ domain ไหน. ปัญหา — CN รับได้แค่ 1 domain. ถ้าบริษัทมี www.example.com, mail.example.com, shop.example.com → ต้องออก cert 3 ใบ

SAN แก้ปัญหานี้ — เป็น list ของ domain ทั้งหมดที่ cert ใบเดียวครอบคลุม. cert ใบเดียวอาจมี SAN เป็น:

1
DNS: www.example.com
2
DNS: mail.example.com
3
DNS: shop.example.com
4
DNS: *.api.example.com   ← wildcard

ในปี 2017 ขึ้นไป — Chrome เลิกใช้ CN ในการ verify domain แล้ว — ใช้แค่ SAN เท่านั้น. ถ้า cert ของบริษัทคุณมีแต่ CN ไม่มี SAN → Chrome จะแสดง warning

มุมผู้บริหาร: ขอทีม IT รัน openssl s_client -connect domain.com:443 -showcerts กับเว็บบริษัทคุณ — 30 วินาทีรู้ทันทีว่า cert ของ Subject ตรงกับชื่อบริษัทจริงไหม + Issuer เป็น CA ที่ตั้งใจใช้ไหม + Validity เหลือกี่วัน. ถ้า Subject เป็น “Default Company Ltd” หรือ Issuer เป็น CA ที่ไม่รู้จัก — ตั้ง config ผิดและอาจถูก hijack

ขั้นที่ 1 — Generate Key Pair + CSR#

ก่อนได้บัตร — บริษัท / เว็บไซต์ต้องทำ 2 อย่าง:

1. Generate key pair ในเครื่อง — ได้ public key + private key คู่หนึ่ง (RSA / ECC ตาม EP.21)
2. สร้าง CSR (Certificate Signing Request) — ไฟล์ที่บรรจุ:
   • public key ที่เพิ่ง generate
   • Subject (ชื่อบริษัท / domain ที่จะใช้)
   • SAN (domain เพิ่มเติม)
   • sign ด้วย private key ของตัวเอง (เพื่อพิสูจน์ว่ามี private key คู่กับ public key นี้จริง)

Private key ห้ามออกจากเครื่อง — ห้ามส่งให้ CA. ถ้าส่งให้ใคร = หมดความหมายของ asymmetric crypto. CSR แนบเฉพาะ public key

ขั้นที่ 2 — Domain Validation + Issue#

บริษัทส่ง CSR ให้ CA. CA ต้อง verify ว่าผู้ขอ “ครอบครอง” domain นั้นจริง ก่อนออก cert ให้. มี 3 method หลัก:

• DV (Domain Validation) — ง่ายและถูกที่สุด. CA ขอให้บริษัทพิสูจน์ความเป็นเจ้าของ domain โดย:
  • HTTP file — วางไฟล์ที่ CA กำหนดใน path เฉพาะ (เช่น /.well-known/acme-challenge/xxx)
  • DNS record — เพิ่ม TXT record ที่ CA กำหนดใน DNS
  • Email — ส่ง verification email ไป [email protected]
• OV (Organization Validation) — CA verify เพิ่ม — ว่าบริษัทมีอยู่จริง — โทรหา registered phone — ตรวจ business registration
• EV (Extended Validation) — verify ลึกที่สุด — ตรวจกฎหมายของบริษัท + ผู้บริหาร + ที่ตั้ง. ในยุคก่อน — browser เคยโชว์ชื่อบริษัทเป็นแถบเขียวที่ address bar. แต่ตั้งแต่ปี 2019 — Chrome / Firefox ยกเลิกการโชว์ green bar ของ EV แล้ว เพราะงานวิจัยพบว่าผู้ใช้ไม่ได้ดูอยู่ดี

verify ผ่าน — CA ใช้ private key ของ Intermediate sign cert → ส่ง cert กลับให้บริษัท

ขั้นที่ 3 — Install + Use#

บริษัท install cert บน web server (Nginx / Apache / IIS / Cloudflare). server ต้องมี 2 ไฟล์:

• certificate file (รวม leaf cert + intermediate cert) — ส่งให้ browser
• private key file — เก็บในเครื่อง — ห้าม commit เข้า git — ห้ามวางใน path ที่ download ได้

private key ของ web server หลุดเข้า GitHub public repo เป็น pattern ที่เห็นได้บ่อยมากในวงการ. ทุก search engine มี crawler ที่หา BEGIN PRIVATE KEY ใน public repo — และหลายเคสในข่าวคือ private key ของ production web หลุดเพราะ developer commit ไฟล์เข้า git โดยลืม .gitignore

ขั้นที่ 4 — Renew หรือ Revoke#

cert ใกล้หมดอายุ → ต้อง renew ก่อนวันหมด. process เหมือนตอนออกครั้งแรก — generate CSR ใหม่ → submit → install ใหม่

ในยุคปัจจุบัน — automation คือคำตอบเดียว. Let’s Encrypt + ACME protocol ทำให้ renew ได้อัตโนมัติทุก 60 วัน. AWS / Azure / GCP มี Certificate Manager service ที่ renew ให้เอง. ถ้าบริษัทคุณยัง renew ด้วยมือ — เตรียมตัวเจอ outage วันที่คนคีย์งานนี้ลาออก

อีกกรณี — ถ้า private key หลุด หรือ server ถูก compromise → ต้อง revoke cert ทันที (ยังไม่หมดอายุก็ revoke ได้). กลไก revocation = หัวข้อถัดไป

มุมผู้บริหาร: Cert lifecycle = supply chain ของความเชื่อ ถ้าบริษัทคุณยังจัดการ cert ด้วย Excel + reminder ใน Outlook = ระเบิดเวลาที่รอจุด action item: ลงทุน automation วันนี้ pattern ของวงการคลาสสิค — บริษัทใหญ่ระดับ Fortune 500 เกิด outage หลายชั่วโมงเพราะลืม renew cert ของ API gateway Cisco / Microsoft Azure / LinkedIn / Stripe / Spotify ทั้งหมดเคยมี outage ใหญ่จากเหตุนี้ cost ของ automation < cost ของ outage 1 ชั่วโมง เสมอครับ

CRL (Certificate Revocation List) — รุ่นแรก ที่ตายไปแล้ว#

CRL = list ทั้งหมดของ cert ที่ถูก revoke — published โดย CA. ทุกครั้งที่ browser ต้องเช็ค cert — ก็ download CRL จาก CA → ค้นหาดูว่า cert ปัจจุบันอยู่ใน list ไหม

ฟังดูตรงไปตรงมา — แต่มี 2 ปัญหาใหญ่ที่ทำให้ตายในทางปฏิบัติ:

ปัญหาที่ 1: CRL ใหญ่มาก

CA ใหญ่ๆ ออก cert หลายล้านใบต่อปี. CRL ที่ active อาจมีขนาด หลาย MB. ทุกครั้งที่ browser เปิดเว็บใหม่ → download หลาย MB → ช้า

ปัญหาที่ 2: CRL ไม่ realtime

CA publish CRL ทุก 24 ชั่วโมง — บางที 7 วัน. ในระหว่างนั้น cert ที่เพิ่ง revoke = ยังถือว่า valid ใน browser ของผู้ใช้

ผลคือ — browser ส่วนใหญ่ตั้งแต่ปี 2012 เป็นต้นมา ไม่ download CRL อีกแล้ว. Chrome ตัดเลย. Firefox ใช้ replacement ที่เรียกว่า CRLite (CRL ที่ compress ด้วย bloom filter)

OCSP (Online Certificate Status Protocol) — รุ่นที่ 2#

OCSP เปลี่ยน approach — แทนที่จะ download list ทั้งหมด → ถาม CA ทีละใบ. browser ส่ง OCSP request ไปที่ OCSP responder ของ CA — ถามว่า “cert serial number XYZ ยังใช้ได้ไหม?”. CA ตอบ “Good” / “Revoked” / “Unknown”

ปัญหาของ OCSP มี 3 ข้อ:

ปัญหาที่ 1: Performance

ทุกครั้งที่ browser เปิดเว็บใหม่ → ต้อง round-trip ไปหา CA ก่อน. ถ้า CA server ของ Verisign / DigiCert ช้า → ผู้ใช้ทั่วโลกที่เปิดเว็บใช้ cert ของ Verisign โหลดช้าตาม

ปัญหาที่ 2: Privacy

CA เห็นทุกเว็บที่ user เปิด. ถ้า browser ถาม “cert ของ gmail.com ใช้ได้ไหม” → CA รู้ว่า user คนนี้กำลังเข้า Gmail. นี่คือ privacy leak ระดับโลก

ปัญหาที่ 3: Soft-fail

ถ้า OCSP responder ของ CA ล่ม → browser ถือว่า cert ใช้ได้ (soft-fail) เพราะถ้า hard-fail = ผู้ใช้เปิดเว็บไม่ได้เลย. โจรรู้จุดนี้ — ถ้าโจร DDoS OCSP responder ของ CA → browser จะ soft-fail → cert ที่ revoke ไปแล้วก็ใช้ต่อได้

OCSP Stapling — ปัจจุบัน best practice#

วงการแก้ปัญหาด้วย OCSP Stapling — server เป็นคนถาม OCSP แทน browser

flow ใหม่:

1. server ของ Google เป็นคนถาม OCSP ของ CA เอง — เช่นทุก 1 ชั่วโมง — ได้ OCSP response มาเก็บไว้
2. ตอน user เปิด mail.google.com — server ส่ง cert + OCSP response ที่ stapled มาด้วย ใน TLS handshake เดียวกัน
3. browser ไม่ต้องถาม CA — เช็ค OCSP response ที่ server แนบมา → เร็วกว่าเดิม

ข้อดี:

• เร็ว — ไม่มี round-trip เพิ่ม
• privacy — CA ไม่รู้ว่า user คนไหนเปิดเว็บไหน
• ไม่มีปัญหา DDoS ของ OCSP responder

ในปี 2026 — OCSP Stapling คือ best practice ที่ทุก web server แนะนำ. Nginx / Apache / Cloudflare ทั้งหมดมี option เปิด stapling

CRL Sets ของ Google + OneCRL ของ Mozilla — Hybrid approach#

ในความเป็นจริง — browser ไม่พึ่ง OCSP / CRL อย่างเดียว. Google + Mozilla มี approach ของตัวเอง:

• CRLSets ของ Google — Google รวบรวม cert ที่ revoked + ที่ “สำคัญพอจะ block” — push เป็น list ไปยัง Chrome ทุกเครื่อง 6-12 ชั่วโมง
• OneCRL ของ Mozilla — list ของ Intermediate CA ที่ Mozilla ตัดสินใจ revoke — push ไปยัง Firefox ทุกเครื่อง

ทั้ง 2 approach คือ “เราไม่เชื่อ OCSP / CRL — เราจัดการเอง สำหรับ cert ที่ critical พอ”

มุมผู้บริหาร: Revocation = จุดที่ PKI อ่อนแอที่สุด ในวงการ. ถ้าบริษัทคุณ deploy web server เอง — เปิด OCSP Stapling ทันที. ตรวจ config nginx / apache → ขอ option ssl_stapling on + ssl_stapling_verify on. ใช้เวลา 5 นาทีของ DevOps. ในมุม risk — ถ้า private key ของบริษัทคุณหลุด + revoke แล้ว → ถ้า browser ของลูกค้าไม่เช็ค revocation = โจรยังใช้ key ที่หลุดได้ต่ออีกนาน. soft-fail behavior ของ browser ทำให้ revoke ในทางปฏิบัติ “ไม่ค่อยมีผล” — ทางแก้คือ short-lived cert (cert อายุสั้น = ไม่ต้องพึ่ง revocation)

DigiNotar 2011 — ราชวงศ์ของฮอลแลนด์ที่ถูกปลอม#

DigiNotar เป็น CA ดัตช์ ที่ออก cert ให้รัฐบาลฮอลแลนด์ — เป็น trusted Root CA ในทุก browser ทั่วโลก. รัฐบาลฮอลแลนด์ใช้ DigiNotar ออก cert ของระบบ tax / health / e-government

ปลายเดือนสิงหาคม 2011 — มีคนใช้ Gmail ในอิหร่าน รายงานว่า Chrome แสดง warning แปลกๆ. ทีม Google เข้าไปดู — พบเรื่องที่ทำให้ทุกคนตกใจ

มีคนใช้ private key ของ DigiNotar Intermediate CA — ออก cert ปลอมของ google.com

มี cert ปลอม ของ:

• *.google.com
• *.microsoft.com
• *.skype.com
• *.twitter.com
• *.wordpress.com
• *.facebook.com
• addons.mozilla.org
• หน่วยข่าวกรองสหรัฐ + อังกฤษ + อิสราเอล

รวม 531 cert ปลอม ที่ออกได้สำเร็จ (รายงานสุดท้ายปรับเป็น 700+ cert) — มีคนเอาไปใช้ทำ MITM กับผู้ใช้ Gmail ในอิหร่าน — ประมาณว่ามีผู้ใช้ที่ถูก MITM 300,000 คน

หลักฐานชี้ไปที่ รัฐบาลอิหร่าน หรือกลุ่มที่ใกล้ชิด — ใช้เพื่อจับนักเคลื่อนไหวที่ใช้ Gmail สื่อสารช่วง Arab Spring

ทำไมไม่มีใครรู้ก่อน 2 เดือน?#

จุดที่ทำให้วงการตกใจที่สุดคือ — DigiNotar ถูก breach ตั้งแต่ 17 มิถุนายน 2011 — แต่กว่าจะถูกเปิดโปง 29 สิงหาคม 2011 — ผ่านไป 2 เดือนกว่า ที่ cert ปลอมถูกใช้ในอิหร่าน

DigiNotar รู้ตัวว่าโดน hack ตั้งแต่ปลายเดือน 6 — แต่ไม่บอกใคร. รอจนกระทั่งผู้ใช้ Gmail ใน Iran เป็นคน whistleblow

ผลลัพธ์ใน 3 สัปดาห์#

• 30 สิงหาคม: Google + Mozilla + Microsoft + Apple distrust DigiNotar Root พร้อมกัน
• 3 กันยายน: รัฐบาลฮอลแลนด์ยึด DigiNotar
• 20 กันยายน: DigiNotar ยื่นล้มละลาย

บริษัทตายภายใน 3 สัปดาห์ หลังเรื่องแดง. นี่คือ blueprint ของวงการว่า — trust ของ CA = สินทรัพย์ที่หายในวันเดียว

ที่ DigiNotar ทิ้งไว้ — Certificate Transparency#

เคส DigiNotar ทำให้ Google + Mozilla ตระหนักว่า — ระบบ PKI ของวงการ “blind”. ไม่มีใครรู้ว่า CA ไหน “กำลังออก cert อะไรอยู่”. CA ออก cert ปลอมได้โดยไม่มีใครเห็น

วิธีแก้ที่ Google คิดในปี 2013 — Certificate Transparency (CT) — log สาธารณะของ cert ทุกใบที่ CA ออก

หลักการของ CT:

1. CA ทุกใบที่จะออก cert ต้อง submit cert เข้า public CT log ก่อน
2. CT log = append-only log ที่ใช้ Merkle tree (EP.22) — ใครก็ลบของในล้อกไม่ได้
3. CT log run โดย Google / Cloudflare / Let’s Encrypt / DigiCert — กระจายอยู่หลายเจ้า
4. browser (Chrome ตั้งแต่ปี 2018) บังคับว่า — cert ที่ไม่อยู่ใน CT log ≥ 2 ที่ → ปฏิเสธ
5. monitor = บริษัทใหญ่อย่าง Google / Facebook สามารถ scan CT log เพื่อหา cert ปลอมของ domain ตัวเอง

ผลคือ — ถ้ามีคนพยายามทำซ้ำเคส DigiNotar ในวันนี้ — Google จะเห็น cert ปลอมของ google.com ใน CT log ภายในชั่วโมง — ไม่ต้องรอ 2 เดือน

CT คือ — “sunlight is the best disinfectant” ในวงการ PKI

Symantec distrust 2018 — เคสที่ใหญ่ที่สุดในวงการหลัง DigiNotar#

ปี 2017-2018 — Google + Mozilla distrust Symantec CA (รวมถึง Thawte / GeoTrust / RapidSSL ที่ Symantec ถือ) หลังจากเจอ Symantec ออก cert ปลอม / misissue 30,000+ cert ในช่วงหลายปี

ผลคือ — 30%+ ของ cert ทั้ง internet ต้องถูก re-issue. DigiCert ซื้อกิจการ Symantec CA แล้วต้อง re-validate ทุก cert ใหม่. นี่คือ cert ที่หมดอายุ + re-issue ใหญ่ที่สุดในประวัติศาสตร์ internet

ข้อเรียนรู้ — ขนาดของ CA ไม่ได้ป้องกัน distrust ได้. Symantec ในปี 2017 คือ CA ที่ใหญ่ที่สุดในวงการ — และก็ตกในเวลา 1 ปีกว่า

Let’s Encrypt 3M revoke ปี 2020 — เคสที่ดีที่สุดของ “หลังบ้านเก่ง”#

มีนาคม 2020 — Let’s Encrypt พบ bug ใน CAA check (Certificate Authority Authorization — DNS record ที่บอกว่า “เฉพาะ CA ตัวนี้ที่ออก cert ให้ domain นี้ได้”) — bug ทำให้ check ของ Let’s Encrypt ผิดสำหรับ 3 ล้านกว่า cert

Let’s Encrypt ประกาศจะ revoke 3+ ล้าน cert ภายใน 24 ชั่วโมง ตาม industry rule. คนทั้งวงการตกใจ — แต่ในที่สุด Let’s Encrypt ลด scope ลงเหลือ ~1.7 ล้าน cert (ที่ยัง active) — และเปิดเครื่องมือให้ลูกค้า re-issue ได้อัตโนมัติผ่าน ACME

ผลคือ — ไม่มี outage ใหญ่. ลูกค้าส่วนใหญ่มี automation อยู่แล้ว — renew ใหม่ใน 24 ชั่วโมง — เรื่องจบ

เคสนี้ตรงข้ามกับ DigiNotar — ทำพลาด + transparent + แก้เร็ว = trust กลับมาภายในสัปดาห์

มุมผู้บริหาร: ทีม security ของบริษัทคุณควรมี CT monitoring ของ domain บริษัทเป็น routine ใช้ tool ฟรีอย่าง crt.sh หรือ Facebook CT Monitor alert ทุกครั้งที่มีคนออก cert ของ *.yourcompany.com ที่ไม่ใช่จากทีม IT pattern ของวงการ — บริษัทใหญ่หลายแห่งพบ cert ปลอมของ subdomain ตัวเองในล้อก CT ก่อน phishing campaign เริ่ม และบล็อกเว็บปลอมได้ก่อนลูกค้าตกเป็นเหยื่อ นี่คือ control ที่ราคา 0 บาท + ROI ระดับวงการ

1. CA Review#

ตรวจ physical security ของ CA คือ ห้องที่เก็บ HSM, biometric, CCTV, dual control เวลา access ตรวจ log การใช้ private key ของ CA ว่าทุกครั้งที่ sign Intermediate ต้องมี log + ลายเซ็น 2 คน

2. RA Review#

ตรวจ process ของ identity verification — RA verify ผู้ขอ cert ยังไง, มี separation of duties จาก CA ไหม, ใครมีสิทธิ์ approve cert request

3. Certificate Policy (CP) Review#

CP = “ใคร trust อะไร และทำไม” เป็นเอกสารระดับ policy ที่บอก stakeholder ว่า CA นี้ใช้สำหรับ use case อะไร, ระดับ assurance เท่าไหร่, ใครเป็น relying party

CP เป็นเอกสารสั้น ปกติ 1-2 หน้า เป็น commitment ระดับสูง

4. Certification Practice Statement (CPS) Review#

CPS = “CA ทำงานตาม CP ยังไง” เอกสาร operational manual ที่บอก how ละเอียดทุกขั้น

CPS เป็นเอกสารยาว ปกติ 50+ หน้า ครอบคลุม key generation, key storage, identity verification procedure, cert issuance procedure, revocation procedure, audit procedure

กับดักของ exam — แยก CP กับ CPS ให้ออก:

• CP = what (high-level policy)
• CPS = how (detailed operational practice)

ถ้า exam ถาม “เอกสารไหนระบุว่า CA จะ verify identity แบบ DV / OV / EV” = CPS (เพราะมัน how) ถ้า exam ถาม “เอกสารไหนระบุว่า CA ใบนี้ใช้สำหรับ banking grade transactions เท่านั้น” = CP (เพราะมัน policy / scope)

5. CRL + OCSP Review#

ตรวจ distribution + freshness ว่า CRL update ตามตาราง Next Update ไหม, OCSP responder up ทั้ง 24/7 ไหม, latency เท่าไหร่

6. Key Management Review#

ตรวจ lifecycle ของ key:

• Key Generation — generate ใน HSM ไหม, ใช้ random source ที่เชื่อได้ไหม
• Key Escrow — ถ้ามี backup ของ private key (สำหรับ recover) เก็บที่ไหน, ใครเข้าถึงได้, ตาม dual control ไหม
• Key Recovery — process ที่ recover key ของพนักงานที่ลาออก (สำหรับ encrypt email เก่า) เป็นยังไง
• Key Destruction — เมื่อ key หมดอายุ destroy ยังไง, มี certificate of destruction ไหม

7. Compliance Review#

ตรวจว่า CA + HSM compliant ตาม:

• FIPS 140-2 หรือ FIPS 140-3 (มาตรฐาน US ของ cryptographic module — Level 1-4)
• PCI DSS ถ้า CA ใช้ในระบบ payment
• WebTrust for Certification Authorities ถ้าเป็น public CA ที่ต้องการอยู่ใน browser trust store
• ETSI EN 319 411 (มาตรฐาน EU เทียบเท่า WebTrust)

มุมผู้บริหาร: ถ้าบริษัทคุณตั้ง internal CA เขียน CP + CPS ตั้งแต่วันแรกครับ หลายบริษัทตั้ง CA ก่อนแล้วค่อยเขียน policy ทีหลัง ผลคือ CA run ไป 2 ปีโดยไม่มีเอกสารว่าทำอะไรอยู่ template ฟรี ของ NIST / Mozilla / Let’s Encrypt มีให้ download adapt มาใช้ได้เลย ตัวเลขใน scope ของ CP / CPS ที่ระบุชัด = ผ่าน audit ได้ครึ่งทาง แล้ว

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — PKI = supply chain ของความเชื่อ. บริษัทคุณพึ่งคนอื่นโดยไม่รู้ตัว

ลองนึกภาพ — บริษัทคุณ secure ระดับโลก. ทีม IT เก่ง. firewall แพง. MFA ครบ. แต่ทุกครั้งที่พนักงานเปิด Salesforce / Office 365 / Gmail — browser ตัดสินใจอัตโนมัติว่าเชื่อเว็บนั้น เพราะ CA ที่บริษัทคุณไม่ได้เลือก vouch ให้

ถ้า CA หนึ่งใน trust store ของ browser พนักงาน — โดน compromise — โจรสามารถออก cert ปลอมของ Salesforce → พนักงาน login เข้าเว็บปลอม → password หลุด. ไม่มีอะไรในระบบของบริษัทคุณจับได้

ทางป้องกัน 3 ข้อในมุมผู้บริหาร:

1. CT monitoring — alert ทุกครั้งที่ใครออก cert ของ domain บริษัท. ใช้ครับ ฟรี
2. HSTS + HPKP/Expect-CT — บังคับ browser ของลูกค้าให้ใช้แค่ HTTPS + cert ที่บริษัทตั้งใจ (EP.24 จะลงลึก)
3. internal CA — ถ้าบริษัทตั้ง CA เอง — Root ต้อง offline + เก็บใน HSM + audit log ครบ. ห้ามมี Root online ในเครื่องที่ใช้งาน

ข้อสอง — Automate cert lifecycle วันนี้. ไม่งั้นจะมี outage

นี่คือ pattern ของวงการคลาสสิคที่ขึ้นข่าวซ้ำซากของบริษัทระดับโลก — บริษัทใหญ่ outage หลายชั่วโมงเพราะลืม renew cert. LinkedIn ครั้งหนึ่ง. Microsoft Teams ครั้งหนึ่ง. Cisco WebEx หลายครั้ง. Spotify หลายครั้ง. ทุกคนพลาดได้ — ถ้ายัง renew ด้วยมือ

3 step ที่ทำได้ทันที:

• inventory cert ทุกใบ ของบริษัท. ใช้ tool อย่าง Cert Spotter หรือ scan port 443 ของ subnet
• set up monitoring + alerting — alert 60 / 30 / 14 / 7 วัน ก่อนหมดอายุ
• ทำ automation — Let’s Encrypt + ACME ฟรี. AWS Certificate Manager / Azure Key Vault สำหรับ cloud workload — มี auto-renew

ถ้าบริษัทคุณยังจัดการ cert ด้วย spreadsheet + Outlook reminder ในปี 2026 — เปลี่ยนเป็น automation ทันที. cost ของ tool < cost ของ outage 1 ชั่วโมงเสมอ