Certificate & CA — vì sao trình duyệt tin một server

TL;DR: Trình duyệt tin một server vì server cầm trong tay một certificate — tài liệu điện tử ghi "domain này thuộc về public key này, được ký bởi tổ chức X". Nhưng ai tin tổ chức X? Câu trả lời là một chuỗi tin cậy (chain of trust): cert của server được ký bởi intermediate CA, intermediate CA được ký bởi root CA, và root CA đã được pre-install vào OS/trình duyệt từ trước. Bạn không cần tin server — bạn tin root CA đã được bạch hóa. Let's Encrypt tự động hoá toàn bộ quy trình này miễn phí. Lỗi cert kinh điển nhất là thiếu intermediate cert — browser cache nó nên không thấy, nhưng curl và mobile fail.

1. Analogy — Chứng chỉ hành nghề có công chứng

Hình dung bạn đến gặp một bác sĩ lần đầu. Bạn không biết họ có đủ năng lực không. Họ đưa cho bạn:

1. Bằng y khoa (leaf certificate) — ghi tên họ, chuyên khoa, ngày cấp, hạn dùng.
2. Dấu công chứng của Bộ Y tế trên bằng đó (chữ ký của intermediate CA).
3. Bộ Y tế được Nhà nước công nhận (root CA — bạn tin vì Nhà nước đã được xác thực từ trước).

Bạn không cần biết bác sĩ này là ai — bạn tin Nhà nước, Nhà nước tin Bộ Y tế, Bộ Y tế ký bằng. Chuỗi tin cậy đóng vòng.

2. Certificate X.509 chứa gì

Một certificate (theo chuẩn X.509, RFC 5280) là một tài liệu có cấu trúc chứa các trường sau:

SAN (Subject Alternative Names) là trường quan trọng nhất khi debug. Trình duyệt hiện đại kiểm tra SAN, không phải CN (Common Name) — cert phải có domain bạn đang truy cập trong SAN, kể cả subdomain. Một cert cho example.com không cover www.example.com trừ khi SAN có cả hai hoặc dùng wildcard *.example.com.

Xem cert thật bằng openssl:

openssl s_client -connect github.com:443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -A 5 "Subject Alternative Name"
# X509v3 Subject Alternative Name:
#   DNS:github.com, DNS:www.github.com

3. Chain of trust — root → intermediate → leaf

Thực tế không bao giờ root CA ký trực tiếp leaf cert. Chuỗi luôn có ít nhất một intermediate CA ở giữa:

flowchart TD
    R["Root CA<br/>(ISRG Root X1)<br/>Tu ky - pre-installed OS"] --> I["Intermediate CA<br/>(Let's Encrypt R11)<br/>Duoc Root CA ky"]
    I --> L["Leaf Certificate<br/>(example.com)<br/>Duoc Intermediate ky"]
    L --> S["Server example.com<br/>Giu private key tuong ung"]

Tại sao cần intermediate CA? Root CA là "vương miện" — private key của nó cực kỳ quý giá và nguy hiểm nếu bị lộ. Root CA phải được giữ offline trong két sắt vật lý (air-gapped HSM). Nếu root CA ký trực tiếp từng cert, nó phải online liên tục — rủi ro cao. Giải pháp: root CA ký một vài intermediate CA (có thể online), intermediate CA ký cert thường ngày. Nếu intermediate bị tấn công, revoke nó là xong — root vẫn an toàn.

Trust store của OS (Windows Certificate Store, macOS Keychain, Linux /etc/ssl/certs/) và trình duyệt chứa danh sách root CA pre-trusted. Khi trình duyệt nhận leaf cert, nó đi theo chuỗi lên root để verify — nếu root có trong trust store, chuỗi được chấp nhận.

4. Self-signed vs CA-signed

Self-signed certificate là cert không có Issuer nào khác — server tự ký cert của chính nó bằng private key của nó. Kỹ thuật không khác gì cert thường, chỉ là không ai đảm bảo danh tính ngoài bản thân server.

5. Let's Encrypt & ACME — cấp cert miễn phí tự động

Let's Encrypt là CA phi lợi nhuận cấp cert DV (Domain Validation) miễn phí thông qua giao thức ACME (Automatic Certificate Management Environment, RFC 8555). Cert có hạn 90 ngày và tự động gia hạn.

ACME hoạt động thế nào:

sequenceDiagram
    participant C as certbot (client)
    participant A as ACME Server (Let's Encrypt)
    participant D as DNS / Web server
    C->>A: Toi muon cert cho example.com
    A-->>C: Challenge: dat file nay tai /.well-known/acme-challenge/<token>
    C->>D: Tao file challenge
    A->>D: GET /.well-known/acme-challenge/<token>
    D-->>A: OK (content dung)
    A-->>C: Domain validated — cert issued
    C->>D: Cai cert moi

Bước quan trọng: Let's Encrypt yêu cầu bạn chứng minh quyền kiểm soát domain qua challenge. Hai loại phổ biến:

• HTTP-01 challenge: đặt một file tại http://example.com/.well-known/acme-challenge/<token> — Let's Encrypt fetch để verify.
• DNS-01 challenge: tạo TXT record _acme-challenge.example.com — dùng khi server không public (staging server, wildcard cert).

Tự động gia hạn với certbot renew hoặc systemd timer — không cần làm gì thủ công sau khi setup.

# Cai certbot (Ubuntu)
sudo apt install certbot python3-certbot-nginx

# Lay cert cho Nginx (HTTP-01 challenge tu dong)
sudo certbot --nginx -d example.com -d www.example.com

# Test gia han (dry run, khong thuc su gia han)
sudo certbot renew --dry-run

6. Lỗi cert thường gặp và cách đọc

Lỗi kinh điển nhất: thiếu intermediate cert. Đây là lỗi hay gặp nhất trong production:

# Kiem tra chain day du
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | grep "s:"
# Phai thay it nhat 2 dong:
# s:CN = example.com         (leaf cert)
# s:CN = Let's Encrypt R11   (intermediate CA)
# s:CN = ISRG Root X1        (root CA — co the khong co vi browser biet san)

7. Kiểm tra cert bằng openssl s_client

openssl s_client là tool debug cert mạnh nhất trên CLI:

# Ket noi va xem cert chain
openssl s_client -connect github.com:443 -showcerts </dev/null

# Output quan trong:
# Certificate chain
#  0 s:CN = github.com    (leaf)
#    i:CN = Let's Encrypt R11 (issuer = intermediate)
#  1 s:CN = Let's Encrypt R11 (intermediate)
#    i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

# Xem ngay het han
openssl s_client -connect github.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -dates
# notBefore=Jan  5 00:00:00 2025 GMT
# notAfter=Apr  5 23:59:59 2025 GMT

# Kiem tra SAN
openssl s_client -connect github.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A 2 "Subject Alternative"

8. Pitfall — hiểu nhầm thường gặp

❌ Nhầm 1: "Thiếu intermediate cert thì mọi client đều báo lỗi." ✅ Không phải. Desktop browser (Chrome, Firefox) cache intermediate CA từ các phiên trước — bạn test thấy ổn. curl, wget, mobile app mới cài, và server-to-server call (Webhook, API client) sẽ fail. Luôn dùng fullchain.pem, không phải cert.pem.

❌ Nhầm 2: "Self-signed cert đủ cho staging." ✅ Self-signed cert khiến mọi HTTP client từ chối kết nối trừ khi bỏ qua verify (curl -k, --insecure). Môi trường staging nên dùng cert thật từ Let's Encrypt với staging ACME server (miễn phí, không rate limit) — giống production, không gây lỗi sai.

❌ Nhầm 3: "Wildcard cert (*.example.com) cover mọi subdomain." ✅ Wildcard chỉ cover một cấp: *.example.com cover api.example.com, www.example.com — nhưng không cover api.v2.example.com hay example.com (không có subdomain). Cần SAN riêng cho domain gốc.

9. Liên hệ các bài khác

• Bài 01 — TLS/HTTPS handshake: Certificate xuất hiện trong bước ServerHello của TLS handshake — bài đó giải thích cơ chế kỹ thuật, bài này giải thích nội dung cert và tại sao trình duyệt tin.
• Bài 03 — Bộ công cụ debug: openssl s_client và curl -v để xem cert thật — bài đó liệt kê cú pháp đầy đủ với output mẫu.
• Bài 06 — Mini-challenge reverse proxy TLS: Bạn sẽ tự issue và cài cert vào Nginx — ứng dụng trực tiếp của bài này.
• Khoá Foundations — Điều gì xảy ra khi gõ URL: TLS/cert là chặng 3 trong bản đồ 5 chặng — bài đó nhắc "xác thực server qua certificate" nhưng không đào sâu.

10. 📚 Deep Dive — tài liệu gốc

11. Tóm tắt

• Certificate X.509 chứa: domain (Subject/SAN), public key, Issuer CA, hạn dùng, chữ ký số của CA.
• Chain of trust: root CA (pre-installed) ký intermediate CA, intermediate ký leaf cert. Trình duyệt verify từ leaf lên root — chuỗi gãy ở đâu là lỗi ở đó.
• Intermediate CA tồn tại để giữ root CA offline an toàn — nếu intermediate bị tấn công, revoke nó mà không ảnh hưởng root.
• SAN (không phải CN) là trường trình duyệt dùng để verify domain — wildcard *.example.com chỉ cover một cấp subdomain.
• Self-signed cert không có bên thứ ba bảo chứng — mọi client từ chối trừ khi bỏ qua verify (-k). Không dùng production.
• Let's Encrypt cấp cert DV miễn phí qua ACME — HTTP-01 hoặc DNS-01 challenge để chứng minh sở hữu domain, gia hạn tự động mỗi 90 ngày.
• Lỗi kinh điển: thiếu intermediate cert — browser cache nên không thấy lỗi, nhưng curl/mobile/API client fail. Luôn dùng fullchain.pem.
• Debug bằng openssl s_client -connect host:443 -showcerts để xem full chain, hạn cert, và SAN.

12. Tự kiểm tra

Bài tiếp theo: Bộ công cụ debug mạng — dig, curl, nc, ss, tcpdump