Chẩn đoán lỗi TLS/HTTPS bằng OpenSSL và curl theo từng lớp

Thông báo “SSL error” không đồng nghĩa certificate chắc chắn bị hỏng. Kết nối có thể thất bại từ DNS, route, firewall, proxy, SNI, hostname, certificate chain, trust store, clock hệ thống hoặc protocol TLS. Nếu bỏ qua các lớp và thử cấu hình ngẫu nhiên, đội vận hành dễ sửa sai chỗ hoặc che lỗi bằng cách tắt xác minh.

Hướng dẫn này xây một quy trình từ thấp lên cao: xác định hostname và IP thực tế, kiểm tra TCP, quan sát handshake, xác minh danh tính certificate, đối chiếu trust store, rồi mới phân tích HTTP. Các lệnh dùng domain tài liệu example.com; hãy thay bằng tên miền thuộc quyền quản lý của bạn.

1. Phân biệt các lớp của một request HTTPS

Không dùng -k hoặc --insecure như một “bản sửa”. Nó chỉ bỏ kiểm tra certificate và có thể biến lỗi cấu hình thành rủi ro man-in-the-middle.

2. Ghi lại bằng chứng trước khi thay đổi

Trước khi restart dịch vụ hoặc cấp lại certificate, hãy ghi nhận thời gian, hostname chính xác, client gặp lỗi, mạng đang dùng, error text và thời điểm bắt đầu. Kiểm tra cùng URL từ hai mạng hoặc hai máy giúp phân biệt lỗi server toàn cục với proxy/trust store cục bộ.

• URL đầy đủ, gồm scheme và port.
• IP được resolve ở client lỗi và client bình thường.
• Phiên bản curl, OpenSSL và TLS backend.
• Thời gian hệ thống và timezone của client/server.
• Thay đổi DNS, load balancer, certificate hoặc proxy gần nhất.

3. Kiểm tra DNS và đường kết nối

# Linux/macOS
dig +short A example.com
dig +short AAAA example.com
nc -vz example.com 443

# Windows PowerShell
Resolve-DnsName example.com
Test-NetConnection example.com -Port 443

Nếu có nhiều A/AAAA record, hãy kiểm tra từng IP. Lỗi chỉ xuất hiện ngẫu nhiên thường do một node trong pool có chain hoặc certificate khác. Nếu IPv6 fail nhưng IPv4 pass, vấn đề có thể nằm ở route, firewall hoặc cấu hình listener IPv6 thay vì PKI.

4. Quan sát handshake với OpenSSL

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts \
  -verify_hostname example.com \
  -verify_return_error

-servername gửi SNI để reverse proxy hoặc web server chọn đúng virtual host và certificate. Kết nối trực tiếp bằng IP nhưng không gửi SNI có thể nhận certificate mặc định, tạo kết luận sai. -showcerts in các certificate server thực sự gửi; nó không tự khẳng định chain hợp lệ.

s_client là công cụ kiểm tra và mặc định có thể tiếp tục handshake sau lỗi verify. Thêm -verify_return_error để lỗi xác minh làm lệnh thất bại rõ ràng. Hãy đọc dòng verify cuối cùng cùng toàn bộ chain, không chỉ nhìn handshake đã hoàn tất.

5. Đọc certificate leaf

Có thể lưu certificate leaf vào file PEM rồi xem các trường quan trọng:

openssl x509 -in leaf.pem -noout \
  -subject -issuer -serial -dates \
  -ext subjectAltName \
  -ext keyUsage \
  -ext extendedKeyUsage

• notBefore và notAfter: cửa sổ hiệu lực.
• subjectAltName: DNS name hoặc IP identity mà certificate bao phủ.
• issuer: CA/intermediate đã ký certificate.
• extendedKeyUsage: mục đích như TLS Web Server Authentication.

Hostname verification hiện đại dựa trên Subject Alternative Name. Wildcard *.example.com thường khớp api.example.com, nhưng không khớp domain gốc example.com và không mở rộng qua nhiều nhãn như a.b.example.com.

6. Certificate chain và lỗi thiếu intermediate

Server thường gửi certificate leaf và các intermediate cần thiết; client đã có root CA trong trust store. Gửi thiếu intermediate có thể hoạt động ở một số browser có cache nhưng fail ở container, CLI hoặc thiết bị sạch. Gửi root không thay thế intermediate bị thiếu.

Đối chiếu từng certificate: issuer của leaf phải nối với subject của intermediate kế tiếp, và chữ ký phải verify được. Khi cấu hình web server, dùng file full chain đúng thứ tự theo hướng dẫn của CA/platform. Không ghép file dựa trên tên đoán.

openssl verify \
  -CAfile root-ca.pem \
  -untrusted intermediate.pem \
  leaf.pem

7. Dùng curl để xem cả TLS và HTTP

curl -vI https://example.com/

# Giữ URL, Host header, SNI và hostname verification,
# nhưng ép kết nối tới IP đang thử nghiệm
curl -vI --resolve example.com:443:203.0.113.20 \
  https://example.com/

# Kiểm tra bằng CA bundle cụ thể
curl -vI --cacert company-ca.pem https://example.com/

--resolve đặc biệt hữu ích trước khi đổi DNS hoặc khi một node trong load balancer có vấn đề. Vì URL vẫn dùng hostname thật, curl giữ SNI và xác minh certificate theo hostname đó. Trái lại, gọi https://203.0.113.20 có thể kiểm tra sai identity và đi vào virtual host mặc định.

Trong output verbose, xác định curl dùng TLS backend và CA store nào, IP nào được kết nối, protocol được thương lượng, kết quả certificate và response HTTP. Chỉ chia sẻ log sau khi xóa cookie, Authorization header, query token và dữ liệu nhạy cảm.

8. Trust store: vì sao máy này pass, máy kia fail?

Cùng một server có thể pass trên browser nhưng fail trong container do trust store khác nhau. Browser, hệ điều hành, Java, Python, curl và appliance có thể dùng kho CA riêng. Image container tối giản cũng có thể chưa cài bundle CA hoặc bundle quá cũ.

• Xác định curl được build với OpenSSL, Schannel, Secure Transport hay backend khác.
• Kiểm tra đường dẫn CA bundle trong output curl -v.
• Cập nhật gói CA bằng package manager của hệ điều hành/image.
• Với private CA, phân phối root qua cơ chế quản trị thiết bị hoặc image build có kiểm soát.
• Không tải một certificate lạ từ kết nối lỗi rồi tin cậy ngay chính certificate đó.

9. Clock và cửa sổ hiệu lực

Client có thời gian sai có thể báo certificate chưa có hiệu lực hoặc đã hết hạn dù server cấu hình đúng. Kiểm tra đồng bộ NTP, timezone và clock của VM/container. Lưu ý certificate hết hạn được đánh giá theo thời gian client; load balancer nhiều node có thể đang phục vụ certificate có ngày khác nhau.

# Linux
date -u
timedatectl status

# PowerShell
Get-Date
w32tm /query /status

10. Phân biệt TLS fail với HTTP fail

Nếu TLS verify thành công nhưng nhận 404, 403 hoặc 502, certificate không còn là nghi phạm chính. Kiểm tra Host header, route của reverse proxy, upstream health, authentication và application log. Mã 301/302 lặp có thể do proxy không truyền đúng scheme hoặc ứng dụng ép HTTPS sai.

Nếu curl hiển thị certificate của công ty thay vì issuer công khai dự kiến, có thể mạng đang dùng TLS inspection proxy. Đây không nhất thiết là tấn công, nhưng client phải tin enterprise root và chính sách doanh nghiệp phải cho phép. So sánh từ mạng ngoài giúp xác nhận.

11. Các lỗi thường gặp và hướng xử lý

12. Quy trình xử lý sự cố ngắn gọn

1. Xác nhận URL, thời gian, phạm vi ảnh hưởng và error nguyên văn.
2. Resolve A/AAAA và test TCP 443 từ đúng client/network.
3. Chạy s_client với SNI, hostname verify và return-on-error.
4. Kiểm tra SAN, dates, issuer và chain server gửi.
5. Dùng curl -vI để tách TLS khỏi HTTP.
6. Dùng --resolve kiểm tra từng node mà không phá hostname verification.
7. Đối chiếu trust store, proxy và clock giữa máy pass/fail.
8. Sửa lớp gây lỗi, sau đó test lại từ bên ngoài và môi trường sạch.

Checklist sau khi sửa

• Hostname thật verify thành công, không dùng --insecure.
• Mọi IP/load balancer node trả cùng certificate chain hợp lệ.
• IPv4 và IPv6 cho kết quả nhất quán nếu đều được công bố.
• Certificate còn đủ thời hạn và có cảnh báo gia hạn.
• Container, CLI, browser và môi trường production quan trọng đều pass.
• Không có secret trong log chẩn đoán đã lưu hoặc chia sẻ.
• Runbook ghi rõ nguyên nhân gốc và phép kiểm tra tái phát.

Tài liệu tham khảo

• OpenSSL: s_client documentation
• curl command-line manual
• curl: TLS certificate verification
• RFC 9525: Service Identity in TLS
• RFC 6066: TLS Server Name Indication

Kết luận

Chẩn đoán TLS hiệu quả là bài toán phân lớp, không phải thử đi thử lại certificate. DNS và TCP cho biết có tới đúng endpoint hay không; SNI chọn đúng virtual host; chain và trust store xác lập niềm tin; hostname xác minh danh tính; curl nối kết quả TLS với HTTP. Giữ nguyên cơ chế verify trong suốt quá trình giúp tìm đúng nguyên nhân mà không tạo một “bản sửa” kém an toàn.