Dựng PKI nội bộ: cấp chứng chỉ SSL cho hệ thống nội bộ miễn phí
Dựng PKI nội bộ: cấp chứng chỉ SSL cho hệ thống nội bộ miễn phí
Hệ thống nội bộ của công ty bạn có bao nhiêu dịch vụ đang chạy HTTP trần? GitLab nội bộ, Jenkins, wiki, dashboard giám sát, các API nội bộ gọi qua lại — mỗi cái một địa chỉ IP hoặc tên miền .local, trình duyệt thì đỏ lòm cảnh báo "Not Secure". Mua chứng chỉ SSL thương mại cho từng cái vừa tốn tiền vừa phiền phức gia hạn. Giải pháp gọn gàng nhất: dựng PKI nội bộ — tự làm "nhà cung cấp chứng chỉ" của chính công ty mình, cấp SSL miễn phí không giới hạn.
PKI (Public Key Infrastructure) nghe thì học thuật, nhưng triển khai thực tế cho SME chỉ cần một server Linux, OpenSSL có sẵn, và một buổi chiều cấu hình cẩn thận. Bài viết này hướng dẫn từng bước xây dựng hệ thống CA nội bộ an toàn, từ tạo Root CA đến cấp phát và thu hồi chứng chỉ trong vận hành hàng ngày.
Dựng pki nội bộ: pKI là gì? Hiểu nhanh trong 3 phút
PKI là hệ thống quản lý việc tạo, cấp phát và thu hồi các cặp khóa mã hóa và chứng chỉ số. Nói đơn giản: đó là "bộ máy" đứng sau mọi ổ khóa số (🔒) bạn thấy trên trình duyệt.
Ba thành phần cốt lõi:
- CA (Certificate Authority) — "cơ quan cấp chứng chỉ": thực thể đáng tin cậy ký xác nhận "khóa công khai này thuộc về server này". Trình duyệt tin website vì tin CA đã ký cho nó.
- Chứng chỉ số (certificate): "chứng minh thư" của server — chứa tên miền, khóa công khai, thời hạn, và chữ ký của CA.
- Cặp khóa (key pair): khóa riêng (giữ bí mật trên server) + khóa công khai (đi kèm chứng chỉ). Dữ liệu mã hóa bằng khóa công khai chỉ giải được bằng khóa riêng.
Vì sao hệ thống nội bộ cần SSL? Ba lý do: (1) mã hóa — ngăn nghe lén trên mạng nội bộ (đừng tưởng mạng LAN là an toàn, malware và insider threat là có thật); (2) xác thực — đảm bảo bạn đang nói chuyện với đúng server chứ không phải kẻ giả mạo (ARP spoofing trong LAN dễ hơn bạn nghĩ); (3) tuân thủ — nhiều chuẩn bảo mật (PCI-DSS, ISO 27001) yêu cầu mã hóa cả traffic nội bộ.
Dựng pki nội bộ: khi nào dùng CA nội bộ, khi nào mua/Let's Encrypt?
| Tình huống | Giải pháp phù hợp |
|---|---|
| Website/app public internet | Let's Encrypt (miễn phí) hoặc CA thương mại |
Dịch vụ chỉ dùng nội bộ (intranet, .local, IP riêng) |
CA nội bộ (PKI tự dựng) |
| Thiết bị IoT, máy in, camera nội bộ | CA nội bộ |
| Môi trường dev/test | CA nội bộ hoặc mkcert |
| Cần EV (xác thực tổ chức hiển thị tên công ty) | CA thương mại |
Quy tắc ngón tay cái: cái gì không public internet được (tên miền nội bộ, IP private) thì Let's Encrypt và CA thương mại không cấp được (họ phải xác minh quyền sở hữu qua internet) — đó chính là "sân nhà" của PKI nội bộ. Ngược lại, đừng bao giờ dùng cert CA nội bộ cho website public — khách hàng bên ngoài không tin CA của bạn.
So sánh nhanh chi phí/năm cho 20 dịch vụ nội bộ:
| Phương án | Chi phí | Quản lý |
|---|---|---|
| Mua cert thương mại × 20 | ~20–60 triệu VNĐ/năm | Gia hạn thủ công từng cái |
| Let's Encrypt | 0đ (nhưng không cấp cho tên miền nội bộ) | Tự động, cần public domain |
| CA nội bộ tự dựng | 0đ | Tập trung, tự động hóa được |
Dựng pki nội bộ: kiến trúc chuẩn: Root CA offline + Intermediate CA
Đừng bao giờ dùng một CA duy nhất cho mọi việc. Kiến trúc an toàn gồm 2 tầng:
Root CA (tầng 1) — "con dấu hoàng gia": - Tự ký (self-signed), thời hạn dài (10–20 năm). - Luôn offline: khóa riêng lưu trên USB/HSM, cất két sắt, chỉ mang ra khi cần ký Intermediate CA mới (vài năm một lần). - Root CA bị lộ = toàn bộ hệ thống PKI sụp đổ và phải làm lại từ đầu. Bảo vệ nó như bảo vệ con dấu công ty.
Intermediate CA (tầng 2) — "người thừa hành": - Được Root CA ký, thời hạn 3–5 năm. - Online trên server an toàn, trực tiếp ký chứng chỉ cho server hàng ngày. - Nếu Intermediate bị lộ, chỉ cần thu hồi nó và ký Intermediate mới từ Root — không phải xây lại toàn bộ.
[Root CA - OFFLINE, két sắt] (20 năm)
│ ký
[Intermediate CA - online] (5 năm)
│ ký
[server1.noidia.vn] [server2.noidia.vn] ... (1-2 năm/chứng chỉ)
Máy trạm chỉ cần cài chứng chỉ Root CA một lần là tự động tin mọi chứng chỉ do hệ thống cấp — đó là toàn bộ "phép màu" của PKI.
Bước 1: Dựng Root CA bằng OpenSSL
Thực hiện trên một máy Linux sạch (có thể là VM tạm, sau đó tắt và lưu image). Cài OpenSSL (thường có sẵn).
1. Tạo thư mục cấu trúc:
mkdir -p /root/ca/{certs,crl,newcerts,private}
chmod 700 /root/ca/private
touch /root/ca/index.txt
echo 1000 > /root/ca/serial
2. Tạo khóa riêng Root CA (4096-bit, mã hóa bằng passphrase mạnh):
openssl genrsa -aes256 -out /root/ca/private/ca.key.pem 4096
chmod 400 /root/ca/private/ca.key.pem
Passphrase này phải được lưu ở nơi an toàn riêng (password manager của công ty + bản giấy trong két). Mất passphrase = mất khả năng dùng Root CA.
3. Tạo chứng chỉ Root tự ký (20 năm):
openssl req -config openssl-root.cnf -key /root/ca/private/ca.key.pem \
-new -x509 -days 7300 -sha384 -extensions v3_ca \
-out /root/ca/certs/ca.cert.pem
Thông tin Distinguished Name nên rõ ràng: CN = Ten Cong Ty Internal Root CA, O = tên công ty. Đừng đặt tên chung chung như "My CA" — 5 năm sau không ai nhớ đó là CA nào.
4. Xác minh và cất giữ:
openssl x509 -noout -text -in /root/ca/certs/ca.cert.pem | head -30
Kiểm tra thời hạn, thuật toán (SHA-384), key usage có Certificate Sign. Sau đó backup toàn bộ thư mục /root/ca ra 2 USB mã hóa, cất 2 nơi khác nhau, rồi tắt máy Root CA.
Bước 2: Tạo Intermediate CA
Thực hiện trên server vận hành (online nhưng hardened: chỉ SSH key, firewall chặt).
1. Tạo khóa và CSR (Certificate Signing Request):
openssl genrsa -aes256 -out /root/intermediate/private/intermediate.key.pem 4096
openssl req -config openssl-intermediate.cnf -new -sha384 \
-key /root/intermediate/private/intermediate.key.pem \
-out /root/intermediate/csr/intermediate.csr.pem
2. Mang CSR sang máy Root CA (USB), ký chứng chỉ 5 năm:
openssl ca -config openssl-root.cnf -extensions v3_intermediate_ca \
-days 1825 -notext -md sha384 \
-in intermediate.csr.pem -out intermediate.cert.pem
3. Mang chứng chỉ về, tạo chuỗi tin cậy (chain):
cat intermediate.cert.pem ca.cert.pem > ca-chain.cert.pem
File ca-chain.cert.pem này sẽ đi kèm mọi chứng chỉ server để client xác minh được đến Root.
Bước 3: Cấp chứng chỉ cho server nội bộ
Giả sử cần cert cho gitlab.noidia.vn. Thực hiện trên chính server đó (khóa riêng không bao giờ rời server — nguyên tắc an toàn cơ bản):
1. Tạo khóa riêng và CSR trên server:
openssl req -new -newkey rsa:2048 -nodes \
-keyout gitlab.noidia.vn.key \
-out gitlab.noidia.vn.csr \
-subj "/CN=gitlab.noidia.vn/O=Ten Cong Ty"
2. Gửi CSR về Intermediate CA, ký (thời hạn 825 ngày ≈ 27 tháng):
openssl ca -config openssl-intermediate.cnf \
-extensions server_cert -days 825 -notext -md sha384 \
-in gitlab.noidia.vn.csr -out gitlab.noidia.vn.crt
Lưu ý về SAN (Subject Alternative Name): trình duyệt hiện đại bỏ qua CN, chỉ tin SAN. File cấu hình server_cert phải có subjectAltName = @alt_names với DNS.1 = gitlab.noidia.vn (thêm DNS.2, IP nếu cần). Quên SAN là lỗi số 1 khiến cert "đúng mà trình duyệt vẫn báo đỏ".
3. Cài lên dịch vụ (ví dụ Nginx):
ssl_certificate /etc/ssl/gitlab.noidia.vn.crt;
ssl_certificate_key /etc/ssl/gitlab.noidia.vn.key;
ssl_trusted_certificate /etc/ssl/ca-chain.cert.pem;
Khởi động lại service và kiểm tra: echo | openssl s_client -connect gitlab.noidia.vn:443 -showcerts.
Bước 4: Phân phối Root CA tới máy trạm
Chứng chỉ server chỉ được tin khi máy client tin Root CA. Triển khai một lần cho toàn công ty:
| Môi trường | Cách triển khai |
|---|---|
| Windows domain | Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root CA |
| Linux (Ubuntu) | Copy ca.cert.pem vào /usr/local/share/ca-certificates/, chạy update-ca-certificates |
| macOS | Triển khai qua MDM (Jamf, Mosyle) hoặc hướng dẫn cài thủ công 1 lần |
| Mobile (MDM) | Đẩy qua profile MDM |
| Trình duyệt Firefox | Có kho cert riêng — cấu hình security.enterprise_roots.enabled=true để dùng cert hệ thống |
Kiểm tra: mở https://gitlab.noidia.vn trên máy nhân viên — phải hiện ổ khóa xanh ngay, không cảnh báo. Nếu còn cảnh báo, 99% là thiếu SAN hoặc chưa cài Root CA đúng kho.
Vận hành hàng ngày: gia hạn, thu hồi, giám sát
Dựng xong chỉ là bắt đầu — PKI sống được nhờ vận hành kỷ luật:
1. Gia hạn trước hạn. Đặt lịch nhắc 60 ngày trước hết hạn cho mọi chứng chỉ (file theo dõi đơn giản hoặc công cụ như Keyfactor/Certbot-style tự chế). Cert hết hạn giữa đêm gây sập dịch vụ "lãng xẹt" — sự cố phổ biến đến mức có hẳn trang theo dõi các vụ lớn.
2. Thu hồi khi cần (revocation). Nhân viên IT nghỉ việc mang theo laptop? Server bị nghi xâm nhập? → thu hồi cert ngay:
openssl ca -config openssl-intermediate.cnf -revoke gitlab.noidia.vn.crt
openssl ca -config openssl-intermediate.cnf -gencrl -out crl.pem
Phân phối CRL tới các service, hoặc triển khai OCSP responder nếu quy mô lớn. PKI không có quy trình thu hồi thì chỉ là "máy in giấy chứng nhận".
3. Tự động hóa. Ở quy mô trên 20 cert, viết script hoặc dùng step-ca (CA mã nguồn mở hỗ trợ ACME nội bộ) để cấp/gia hạn tự động như Let's Encrypt nhưng cho mạng nội bộ. Đầu tư một lần, nhàn 5 năm.
4. Audit định kỳ. Mỗi 6 tháng rà soát: còn bao nhiêu cert đang hiệu lực? Của ai? Có cert nào cấp cho server đã nghỉ hưu không? Thu hồi dọn dẹp định kỳ.
Bảo vệ khóa riêng: phần nhiều người làm ẩu nhất
Toàn bộ PKI đứng trên khóa riêng của CA. Lộ khóa = kẻ tấn công tự ký cert giả mạo mọi dịch vụ nội bộ của bạn.
| Cấp độ bảo vệ | Cách làm | Phù hợp |
|---|---|---|
| Cơ bản | File + passphrase mạnh, permission 400, backup mã hóa | SME nhỏ, ít dịch vụ |
| Khá | USB token mã hóa (YubiKey) lưu khóa CA | Khuyến nghị cho hầu hết SME |
| Cao | HSM (Hardware Security Module) | Tổ chức lớn, yêu cầu tuân thủ nghiêm |
Nguyên tắc bất di bất dịch: - Khóa Root CA không bao giờ nằm trên máy online. - Passphrase lưu tách biệt khỏi file khóa (một nơi giữ file, một nơi giữ passphrase). - Mọi lần dùng Root CA đều ghi log: ai, khi nào, để ký cái gì, có 2 người chứng kiến.
Kết luận
Dựng PKI nội bộ là khoản đầu tư một buổi chiều mang lại lợi ích nhiều năm: chứng chỉ SSL miễn phí không giới hạn cho mọi dịch vụ nội bộ, mã hóa toàn bộ traffic LAN, và nền nếp bảo mật chuyên nghiệp. Công thức an toàn gồm 3 điểm: Root CA offline + Intermediate online, mọi cert có SAN đầy đủ, và quy trình gia hạn/thu hồi được vận hành kỷ luật.
Nếu đội ngũ của bạn muốn triển khai PKI nhưng thiếu người có kinh nghiệm, SunCloud cung cấp dịch vụ tư vấn bảo mật hạ tầng cùng Cloud Server dùng thử 10 ngày để dựng lab PKI thử nghiệm. Liên hệ hotline 083 979 3434 hoặc email sales@suncloud.vn hoặc truy cập suncloud.vn.
Bài viết liên quan
- Dịch vụ VPS SunCloud
- Proxmox Backup Server: dựng hệ thống backup cho VM miễn phí
- Checklist 10 điểm kiểm tra an toàn hệ thống thông tin theo cấp độ
Câu hỏi thường gặp
PKI nội bộ khác gì Let's Encrypt?
Let's Encrypt là CA công cộng — chỉ cấp cho tên miền public xác minh được qua internet, miễn phí nhưng không cấp cho tên miền nội bộ/IP private. PKI nội bộ do bạn tự làm CA, cấp được cho mọi tên miền nội bộ nhưng chỉ máy trong công ty (đã cài Root CA) mới tin.
Có nên dùng cert tự ký (self-signed) từng cái thay vì dựng PKI?
Không nên khi có trên 3–5 dịch vụ. Mỗi cert tự ký phải được từng máy client "ngoại lệ" thủ công — vừa phiền vừa tạo thói quen xấu (người dùng quen bấm "bỏ qua cảnh báo"). PKI chỉ cần cài Root CA một lần cho tất cả.
Root CA nên để thời hạn bao lâu?
20 năm là phổ biến. Root CA thay thế rất phiền (phải cài lại trên mọi máy trạm), nên để dài. Ngược lại chứng chỉ server chỉ nên 1–2 năm để buộc quy trình gia hạn vận hành thường xuyên — cert càng dài càng dễ "quên".
Mất khóa riêng của Intermediate CA thì sao?
Thu hồi Intermediate cũ, dùng Root CA (offline) ký Intermediate mới, cấp lại cert cho các server. Gián đoạn có nhưng khắc phục được trong ngày — đây chính là lý do kiến trúc 2 tầng tồn tại.
Có công cụ nào thay OpenSSL cho dễ dùng không?
Có: step-ca (Smallstep) cung cấp CA với API và ACME nội bộ, dễ tự động hóa hơn OpenSSL thuần. EJBCA (mã nguồn mở) cho nhu cầu enterprise. Nhưng hiểu OpenSSL trước vẫn là nền tảng cần thiết để xử lý sự cố.
