CA gửi một bộ chứng chỉ, mỗi nền tảng đòi một kiểu: Nginx, IIS, HAProxy, F5, Tomcat, WAF

Mua SSL cho congtyabc.vn, nhà cung cấp gửi về một email với vài file đính kèm. Cùng bộ file đó, người dùng Nginx cài xong trong hai phút; người dùng IIS mở hộp thoại Import ra thì không có ô nào để bỏ file .key vào; người dùng HAProxy trỏ đúng đường dẫn mà service không khởi động được; người dùng F5 BIG-IP thì không biết nạp file .ca-bundle vào đâu.

Không ai làm sai cả. CA cấp chứng chỉ theo một chuẩn chung, còn mỗi nền tảng lại đóng gói theo cách riêng của nó. Việc bạn phải làm nằm ở giữa: đổi cách đóng gói, không đổi nội dung.

Bài này đi theo thứ tự thực tế — bạn đang cầm gì, nền tảng của bạn đòi gì, và chuyển bằng cách nào.

CA gửi cho bạn những gì

Gần như mọi nhà cung cấp đều gửi ba thứ, tên file có thể khác nhau:

Thứ	Tên hay gặp	Là gì
Chứng chỉ của bạn	certificate.crt, your_domain.pem, cert.cer	chứng chỉ đã ký cho tên miền của bạn
Chuỗi trung gian	ca-bundle.crt, chain.pem, intermediate.crt	các chứng chỉ CA trung gian nối chứng chỉ của bạn về root
Đôi khi thay cả hai	certificate.p7b	một container gộp chứng chỉ + chuỗi (hay gặp khi đặt hàng qua kênh thiên Windows)

Và thứ thứ tư, CA không bao giờ có: private key. Nó sinh ra trên máy bạn lúc tạo CSR và không rời khỏi đó. Nếu bạn làm mất, không ai cấp lại được — phải xin cấp lại chứng chỉ với CSR mới.

Một điểm khiến nhiều người mất thời gian oan: đuôi file nói dối. .crt và .cer có thể là văn bản PEM, cũng có thể là nhị phân DER. Mở bằng Notepad, thấy dòng đọc được bắt đầu bằng -----BEGIN CERTIFICATE----- thì là PEM; thấy ký tự nhị phân lộn xộn thì là DER hoặc một container nhị phân khác.

Nginx và Apache — PEM, nhưng chuỗi phải nằm đúng chỗ

Đây là trường hợp dễ nhất, và cũng là nơi lỗi "chuỗi không đầy đủ" hay xuất hiện nhất.

Nginx nhận một file chứng chỉ chứa chứng chỉ của bạn rồi tới các chứng chỉ trung gian, nối tiếp nhau trong cùng một file, và một file khóa riêng:

ssl_certificate      /etc/ssl/certs/fullchain.pem;   # cert của bạn + chuỗi
ssl_certificate_key  /etc/ssl/private/private.key;

Apache 2.4.8 trở lên cũng vậy: SSLCertificateFile chứa cert kèm chuỗi, SSLCertificateKeyFile chứa khóa. Chỉ thị SSLCertificateChainFile đã bị khai tử, đừng dùng lại theo hướng dẫn cũ trên mạng.

Thứ tự trong file là bắt buộc: chứng chỉ của bạn phải đứng đầu tiên. Đảo ngược lại thì Nginx vẫn khởi động, nhưng trình duyệt sẽ báo lỗi chuỗi — kiểu lỗi khó chịu vì máy bạn thường vẫn vào được, chỉ khách mới gặp.

Nếu CA gửi bạn file .p7b: dùng P7B → PEM để bóc toàn bộ chứng chỉ bên trong ra thành một file PEM. Lưu ý: công cụ giữ nguyên thứ tự các chứng chỉ như chúng nằm trong file P7B, không tự sắp lại — nên hãy mở file kết quả ra và kiểm chứng chỉ của bạn có đang ở trên cùng không trước khi trỏ Nginx vào đó. Muốn biết khối nào là của mình, nhìn dòng subject= khi soi bằng OpenSSL, hoặc đơn giản là khối đầu tiên trong file P7B thường đã là chứng chỉ leaf.

Nếu CA gửi file nhị phân DER: DER → PEM đưa nó về dạng văn bản dán được vào cấu hình.

HAProxy — tất cả trong một file PEM, kể cả khóa

HAProxy khác Nginx ở một điểm khiến nhiều người vấp: nó muốn một file PEM duy nhất chứa cả private key.

bind *:443 ssl crt /etc/haproxy/certs/congtyabc.vn.pem

File đó phải gồm, nối tiếp nhau: chứng chỉ của bạn → chuỗi trung gian → private key. Vẫn là các khối PEM ghép lại, chỉ là ghép thêm khóa vào cuối.

Nghĩa là bạn không cần "chuyển đổi" gì nếu đã có sẵn PEM — chỉ cần ghép file. Nhưng bạn sẽ cần công cụ trong hai tình huống:

• CA gửi .p7b → P7B → PEM trước, rồi mới ghép khóa vào.
• Bạn chỉ còn file .pfx từ một server Windows cũ → PFX → PEM tách ra chứng chỉ và khóa, rồi ghép lại theo thứ tự trên.

Vì file này chứa private key ở dạng không mã hoá, hãy đặt quyền chặt cho nó (chmod 600, chủ sở hữu là user chạy HAProxy) và đừng để nó lọt vào git.

IIS, Windows Server, Exchange — .pfx

Đây là nhóm bắt buộc phải chuyển đổi thật, vì Windows đóng gói theo chuẩn khác hẳn.

IIS Manager → Server Certificates → Import chỉ nhận đúng một loại file: .pfx (còn gọi là PKCS#12). File đó chứa luôn private key bên trong — đó là lý do IIS chỉ cần một file, và cũng là lý do PFX luôn có mật khẩu.

Chọn công cụ theo thứ bạn đang cầm:

Bạn đang có	Công cụ
.pem + private key	PEM → PFX
.crt + private key	CRT → PFX
.p7b + private key	P7B → PFX

Vì sao P7B vẫn phải nhập private key riêng? Vì P7B theo chuẩn không bao giờ chứa private key — nó chỉ gom chứng chỉ. Tiện để chuyển chuỗi, nhưng không thay được file .key.

Vài điểm thực dụng khi dựng PFX:

• Công cụ tự đối chiếu key với chứng chỉ trước khi dựng file. Không khớp thì nó dừng và báo thẳng, thay vì tạo ra một file hỏng mà tới lúc import vào IIS bạn mới biết. Đây là lỗi tốn thời gian nhất khi cài SSL lên Windows, thường do tạo CSR hai lần rồi lấy nhầm khóa.
• Mật khẩu tối thiểu 8 ký tự, có thanh đo độ mạnh và ô nhập lại. BKNS không giữ và không khôi phục được mật khẩu này — không máy chủ nào của chúng tôi biết nó. Lưu lại trước khi đóng tab.
• Ô thuật toán mã hóa để mặc định 3DES là hợp lý cho hầu hết trường hợp: đó là kiểu mã hóa PKCS#12 mà Windows đọc được ổn định suốt hai thập kỷ. Chỉ chọn AES-256 khi tổ chức có quy định tuân thủ cấm 3DES, đổi lại file cần Windows đời mới hơn.
• Nếu khóa của bạn là ECDSA, chiều dựng PFX hiện chưa hỗ trợ; trang báo ngay lúc nạp file và đưa sẵn lệnh OpenSSL tương đương. Giới hạn này chỉ áp cho chiều dựng — đọc một file PFX có sẵn thì thuật toán nào cũng được.

F5 BIG-IP — chứng chỉ và khóa là hai đối tượng tách rời

F5 không nhận một file gộp theo kiểu HAProxy. Trong System → Certificate Management → Traffic Certificate Management, bạn nạp:

• Certificate — chứng chỉ của bạn, dạng PEM
• Key — private key, dạng PEM
• Certificate chain / CA bundle — chuỗi trung gian, nạp thành một đối tượng riêng rồi tham chiếu trong Client SSL profile

Nghĩa là nếu CA đã gửi bạn PEM rời thì thường không phải chuyển đổi gì. Bạn cần công cụ khi:

• CA gửi .p7b → P7B → PEM để lấy chứng chỉ và chuỗi ra dạng PEM.
• Bạn đang di chuyển từ Windows sang và chỉ còn .pfx → PFX → PEM tách thành chứng chỉ + khóa để nạp vào hai ô tương ứng.
• File CA gửi là nhị phân DER → DER → PEM.

F5 cũng hỗ trợ nhập thẳng gói PKCS#12, nên đường PEM → PFX cũng dùng được nếu bạn thích nạp một lần cả cặp.

Tomcat và ứng dụng Java — PKCS#12, rồi mới tới JKS

Tomcat 8.5 trở lên đọc trực tiếp keystore dạng PKCS#12 — tức chính file .pfx:

<Certificate certificateKeystoreFile="conf/congtyabc.p12"
             certificateKeystoreType="PKCS12"
             certificateKeystorePassword="..." />

Nên đường đi ngắn nhất là dựng PFX bằng PEM → PFX rồi trỏ Tomcat vào đó. Đuôi .p12 hay .pfx không quan trọng, cùng một định dạng.

Nếu hệ thống của bạn bắt buộc dùng JKS (Java KeyStore, định dạng cũ của Oracle), bộ công cụ này không tạo JKS — nhưng bạn chỉ còn một bước, làm bằng keytool có sẵn trong JDK:

keytool -importkeystore \
  -srckeystore congtyabc.p12 -srcstoretype PKCS12 \
  -destkeystore congtyabc.jks -deststoretype JKS

Từ Java 9 trở đi PKCS#12 đã là định dạng keystore mặc định, nên nếu không có ràng buộc cũ thì đừng tự chuyển sang JKS làm gì.

WAF, CDN và thiết bị mạng — thường là dán PEM

Cloudflare, Imperva, các WAF dạng appliance, load balancer phần cứng, máy in mạng, thiết bị lưu trữ — nhóm này phần lớn cho bạn dán trực tiếp nội dung PEM vào một ô văn bản: một ô cho chứng chỉ (kèm chuỗi), một ô cho private key.

Việc cần làm thường chỉ là đưa mọi thứ về PEM đọc được:

• Đang cầm nhị phân → DER → PEM
• Đang cầm .p7b → P7B → PEM
• Đang cầm .pfx → PFX → PEM, hoặc PFX → CRT nếu thiết bị chỉ cần chứng chỉ mà không cần khóa

Một số thiết bị đời cũ lại đi ngược: chỉ nhận file nhị phân DER. Khi đó dùng PEM → DER.

Và đôi khi vấn đề chỉ là cái đuôi file — hệ thống từ chối .pem nhưng nhận .crt dù ruột giống hệt nhau. PEM → CRT và CRT → PEM xử lý đúng chuyện đó, kèm chuẩn hoá lại xuống dòng cho đúng chuẩn.

Bảng tra nhanh

Nền tảng	Đòi gì	Từ bộ file CA gửi, làm gì
Nginx / Apache	cert+chuỗi một file, key một file	ghép PEM; nếu có .p7b → P7B → PEM
HAProxy	một file PEM gồm cả key	ghép cert + chuỗi + key; từ .pfx → PFX → PEM
IIS / Exchange / .NET	.pfx	PEM · CRT · P7B → PFX
F5 BIG-IP	cert / key / chain rời	giữ PEM; hoặc PFX → PEM khi rời Windows
Tomcat / Java	PKCS#12 (rồi JKS nếu cần)	PEM → PFX, sau đó keytool nếu bắt buộc JKS
WAF / CDN / thiết bị	dán PEM	đưa về PEM: DER→PEM · P7B→PEM
Thiết bị cũ chỉ nhận nhị phân	DER	PEM → DER

Kiểm tra trước khi mang lên server thật

Với file PFX, nếu máy bạn có OpenSSL:

openssl pkcs12 -in certificate.pfx -info -nodes -passin pass:MAT_KHAU_CUA_BAN

Cần thấy đủ ba điều: không có lỗi MAC could not be verified (mật khẩu đúng), subject= hiện đúng tên miền, và có một khối PRIVATE KEY. Thêm -nokeys để chỉ liệt kê chứng chỉ, xem chuỗi đã đủ chưa.

Không có OpenSSL? Nạp chính file .pfx vừa tạo vào PFX → CRT — mở được bằng đúng mật khẩu bạn vừa đặt nghĩa là file lành.

Câu hỏi thường gặp (FAQ)

Vì sao không có một nút "chuyển đổi tất cả" mà lại tách thành 10 trang? Vì mỗi cặp định dạng cần đúng những dữ liệu khác nhau. Dựng PFX cần chứng chỉ và private key; đổi PEM sang DER thì chỉ cần chứng chỉ và không có ô nào để nhập khóa — vì nó không cần tới khóa. Tách ra nghĩa là trang chỉ hỏi đúng thứ nó dùng, và bạn không bao giờ dán private key vào một công cụ vốn không cần nó.

Chứng chỉ của tôi dùng ECDSA thì sao? Chỉ chiều dựng file PFX là giới hạn ở RSA, và trang báo ngay khi bạn nạp file kèm lệnh OpenSSL thay thế. Đọc một file PFX có sẵn thì thuật toán nào cũng được. Năm hướng đổi vỏ (PEM/DER/CRT/P7B) thậm chí không đọc tới thuật toán khóa nên không giới hạn.

Tôi thiếu chuỗi trung gian thì có sao không? Cài vẫn được, nhưng một phần trình duyệt và thiết bị di động sẽ báo lỗi chuỗi không đầy đủ — và thường máy của bạn lại vào bình thường vì đã cache chuỗi từ trước, nên lỗi rất dễ bị bỏ sót. Xin lại file .ca-bundle từ nhà cung cấp; thường nó nằm ngay trong email cấp chứng chỉ.

Tôi mất private key, có công cụ nào cứu không? Không, và không nên tin bất kỳ công cụ nào nói ngược lại. Private key không nằm ở CA và không suy ngược ra được từ chứng chỉ. Cách duy nhất là tạo CSR mới và xin cấp lại chứng chỉ.

Đưa private key lên một công cụ web có an toàn không? Đây là câu hỏi đúng phải hỏi. Nguyên tắc: đừng đưa private key cho công cụ không cần tới nó — và đó chính là lý do bộ này tách 10 trang, năm trong số đó không có ô nhập khóa.

Với các trang thật sự cần khóa (dựng và đọc PFX), điều bạn nên đòi hỏi là khóa không rời máy mình và tự kiểm chứng được thay vì phải tin lời hứa. Cách kiểm: mở DevTools, tab Network, để bộ lọc ở mức All rồi chạy chuyển đổi. Bạn sẽ thấy một request tới /track — đó là tín hiệu đếm lượt dùng, nội dung chỉ là thời gian xử lý, gửi bằng sendBeacon nên nằm ở nhóm ping/Other. Không có request nào mang nội dung file hay mật khẩu.

Vì sao không dùng luôn tính năng mã hoá sẵn có của trình duyệt? Web Crypto API không hỗ trợ PKCS#12, nên không thể dựng hay đọc .pfx bằng riêng API gốc. Công cụ dùng thư viện mã nguồn mở node-forge chạy ngay trong trình duyệt.

---

BKNS Tools — bộ chuyển đổi SSL 10 hướng, miễn phí, chạy hoàn toàn trên trình duyệt. Dựng PFX: PEM → PFX · CRT → PFX · P7B → PFX Đọc PFX: PFX → PEM · PFX → CRT Đổi vỏ: PEM → DER · DER → PEM · PEM → CRT · CRT → PEM · P7B → PEM Xem tất cả: trang tổng hợp bộ chuyển đổi SSL — không cần đăng nhập.