Home » PKI and Certificates: X.509, CA Hierarchy, Certificate Lifecycle, ACME และ mTLS
PKI and Certificates: X.509, CA Hierarchy, Certificate Lifecycle, ACME และ mTLS
PKI and Certificates: X.509, CA Hierarchy, Certificate Lifecycle, ACME และ mTLS
PKI (Public Key Infrastructure) เป็นระบบที่จัดการ digital certificates สำหรับ secure communications X.509 เป็น standard format ของ digital certificates, CA Hierarchy สร้าง chain of trust จาก Root CA → Intermediate CA → End-Entity, Certificate Lifecycle ครอบคลุม issuance, renewal, revocation, ACME protocol (Let’s Encrypt) ทำให้ certificate issuance อัตโนมัติ และ mTLS (Mutual TLS) ให้ทั้ง server และ client authenticate ซึ่งกัน
ทุกครั้งที่เข้าเว็บ HTTPS จะมี PKI ทำงานอยู่เบื้องหลัง: browser ตรวจสอบ certificate ของ server → verify chain of trust → establish encrypted connection ถ้า PKI ถูก compromise (เช่น CA ถูก hack) จะกระทบความปลอดภัยของ Internet ทั้งหมด การเข้าใจ PKI เป็น fundamental สำหรับ security professionals
X.509 Certificate Fields
| Field |
Purpose |
Example |
| Subject |
ใครเป็นเจ้าของ certificate |
CN=www.example.com, O=Example Inc, C=TH |
| Issuer |
CA ที่ issue certificate |
CN=Let’s Encrypt Authority X3, O=Let’s Encrypt |
| Serial Number |
Unique identifier ของ certificate |
03:A1:B2:C3:D4:E5:F6:78 |
| Validity (Not Before/After) |
ช่วงเวลาที่ certificate valid |
2024-01-01 to 2024-12-31 |
| Public Key |
Public key ของ subject |
RSA 2048-bit หรือ ECDSA P-256 |
| SAN (Subject Alternative Names) |
Additional domains/IPs ที่ certificate cover |
DNS:example.com, DNS:*.example.com, IP:10.0.0.1 |
| Key Usage |
อนุญาตให้ใช้ key ทำอะไรบ้าง |
Digital Signature, Key Encipherment |
| Signature |
Digital signature จาก issuer CA |
SHA256withRSA |
CA Hierarchy
| Level |
Role |
Security |
| Root CA |
Top of trust chain — self-signed certificate |
Offline, HSM-protected, air-gapped (ใช้ issue intermediate CAs เท่านั้น) |
| Intermediate CA (Issuing CA) |
Issue end-entity certificates |
Online, HSM-protected (compromise ไม่กระทบ Root CA) |
| End-Entity Certificate |
Server/client certificate ที่ใช้งานจริง |
Stored on server (private key must be protected) |
Certificate Types
| Type |
Validation Level |
Use Case |
| DV (Domain Validation) |
ยืนยันว่าเป็นเจ้าของ domain (DNS/HTTP challenge) |
Websites ทั่วไป, APIs (Let’s Encrypt = free DV) |
| OV (Organization Validation) |
ยืนยัน domain + organization identity |
Business websites (แสดง organization name ใน cert) |
| EV (Extended Validation) |
ยืนยัน domain + organization + legal entity |
Banks, financial institutions (strict verification process) |
| Wildcard |
Cover *.domain.com (ทุก subdomain) |
Multiple subdomains (app.example.com, api.example.com) |
| Multi-Domain (SAN) |
Cover หลาย domains ใน 1 certificate |
Multiple domains (example.com + example.org + example.net) |
Certificate Lifecycle
| Phase |
Action |
| 1. Key Generation |
สร้าง key pair (RSA 2048/4096 หรือ ECDSA P-256/P-384) |
| 2. CSR (Certificate Signing Request) |
สร้าง CSR ด้วย subject info + public key → ส่งให้ CA |
| 3. Validation |
CA verify domain ownership (DV) หรือ organization (OV/EV) |
| 4. Issuance |
CA sign certificate → return signed cert + chain |
| 5. Installation |
Install cert + private key + chain บน server |
| 6. Monitoring |
Monitor expiration date → alert ก่อนหมดอายุ |
| 7. Renewal |
Renew ก่อนหมดอายุ (ACME = auto-renew) |
| 8. Revocation |
Revoke ถ้า private key compromised → CRL/OCSP |
ACME Protocol (Let’s Encrypt)
| Feature |
รายละเอียด |
| คืออะไร |
Automated Certificate Management Environment — auto issue/renew certificates |
| Let’s Encrypt |
Free, open CA ที่ใช้ ACME protocol (issue 300M+ active certs) |
| HTTP-01 Challenge |
Place file at http://domain/.well-known/acme-challenge/ → CA verifies |
| DNS-01 Challenge |
Create DNS TXT record → CA verifies (required for wildcard certs) |
| Certbot |
Official ACME client — auto request, install, renew certificates |
| Validity |
90 days (short = force automation, limit damage if compromised) |
| Auto-Renewal |
Certbot cron job renew ทุก 60 วัน (30 วันก่อนหมดอายุ) |
mTLS (Mutual TLS)
| Feature |
Standard TLS |
mTLS |
| Server Auth |
ใช่ (client verify server cert) |
ใช่ |
| Client Auth |
ไม่ (client ไม่ต้อง cert) |
ใช่ (server verify client cert ด้วย) |
| Use Case |
Public websites (HTTPS) |
API-to-API, microservices, zero trust, IoT |
| Certificates Needed |
Server cert only |
Server cert + client cert (both from trusted CA) |
| Security |
Encrypt + server identity |
Encrypt + server identity + client identity (strongest) |
Certificate Revocation
| Method |
How |
Pros/Cons |
| CRL (Certificate Revocation List) |
CA publishes list of revoked cert serial numbers |
Simple but CRL grows large, clients must download |
| OCSP (Online Certificate Status Protocol) |
Client queries CA for specific cert status (real-time) |
Real-time but privacy concern (CA knows which sites you visit) |
| OCSP Stapling |
Server queries OCSP → staples response to TLS handshake |
Best: real-time + privacy (client doesn’t contact CA) |
ทิ้งท้าย: PKI = Trust Infrastructure of the Internet
PKI and Certificates X.509: standard cert format (subject, issuer, validity, public key, SAN, signature) CA Hierarchy: Root CA (offline) → Intermediate CA (online, issues certs) → End-Entity Cert Types: DV (domain only, free), OV (+ org), EV (+ legal entity), wildcard, multi-domain Lifecycle: key gen → CSR → validation → issuance → install → monitor → renew → revoke ACME: automated cert management (Let’s Encrypt = free DV, 90-day validity, auto-renew) mTLS: both server + client present certificates (strongest auth for APIs/microservices) Revocation: CRL (list), OCSP (real-time query), OCSP Stapling (best — server staples response)
อ่านเพิ่มเติมเกี่ยวกับ DNS Security DNSSEC DoH DoT และ Zero Trust Architecture ZTNA ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
