Cách xử lý lỗi CERTIFICATE_VERIFY_FAILED khi dùng HTTPS qua proxy

Hiểu đúng lỗi CERTIFICATE_VERIFY_FAILED khi dùng proxy

Lỗi CERTIFICATE_VERIFY_FAILED xuất hiện khi ứng dụng không thể xác thực chứng chỉ của đầu kết nối TLS theo chính sách đang áp dụng. Khi truy cập HTTPS qua proxy, nguyên nhân có thể nằm ở máy chủ đích, proxy, kho chứng chỉ tin cậy hoặc cấu hình của ứng dụng.

Cách xử lý đúng không phải là tắt kiểm tra chứng chỉ, mà là xác định đầu kết nối đang được xác thực, kiểm tra chuỗi chứng chỉ và cung cấp nguồn tin cậy phù hợp. Điều này giúp duy trì cả mã hóa đường truyền lẫn khả năng xác thực danh tính máy chủ.

Proxy ảnh hưởng đến xác minh TLS như thế nào?

Proxy chuyển tiếp đường hầm CONNECT

Với HTTP proxy sử dụng CONNECT, proxy thiết lập đường hầm đến máy chủ đích. Nếu không có kiểm tra HTTPS tại proxy hoặc một thiết bị trung gian khác, phiên TLS được thiết lập giữa ứng dụng và máy chủ đích; proxy không thay thế chứng chỉ của website.

Trong trường hợp này, không nên mặc định rằng ứng dụng cần chứng chỉ CA proxy. Lỗi có thể xuất phát từ chuỗi chứng chỉ máy chủ thiếu thành phần trung gian, kho CA cũ, đồng hồ hệ thống sai hoặc tên máy chủ không khớp.

Proxy có chức năng kiểm tra HTTPS

Proxy kiểm tra HTTPS tạo hai kết nối TLS riêng, nên ứng dụng cần tin cậy CA được tổ chức phê duyệt.

Trong một số mạng doanh nghiệp, proxy được quản trị để kiểm tra lưu lượng HTTPS. Thiết bị kết thúc kết nối TLS từ ứng dụng, rồi thiết lập một kết nối TLS riêng đến máy chủ đích.

Ứng dụng lúc này nhận chứng chỉ do hạ tầng CA của tổ chức phát hành. Để xác thực thành công, ứng dụng phải tin cậy CA được tổ chức phê duyệt, đồng thời chứng chỉ vẫn phải đáp ứng yêu cầu về tên miền, thời hạn và chuỗi tin cậy.

Kết nối đến chính proxy cũng dùng TLS

Nếu ứng dụng hỗ trợ kết nối tới proxy bằng HTTPS, có thể tồn tại một lớp TLS đến proxy và một lớp TLS đến máy chủ đích. Hai lớp này có thể sử dụng cấu hình CA khác nhau.

Do đó, cần đọc lỗi để xác định chứng chỉ nào bị từ chối. Bổ sung CA cho kết nối tới website chưa chắc giải quyết được lỗi xác thực chứng chỉ của chính proxy.

Đọc thông báo lỗi trước khi thay đổi cấu hình

CERTIFICATE_VERIFY_FAILED là thông báo tổng quát. Phần mô tả đi kèm thường giúp phân loại nguyên nhân:

• Unable to get local issuer certificate: ứng dụng không xây dựng được chuỗi tin cậy đến CA được chấp nhận; có thể thiếu CA gốc hoặc chứng chỉ trung gian.
• Self-signed certificate in certificate chain: chuỗi có chứng chỉ tự ký nhưng chưa thiết lập được quan hệ tin cậy phù hợp.
• Certificate has expired: chứng chỉ trong chuỗi hết hạn hoặc thời gian trên máy khách không chính xác.
• Hostname mismatch: tên máy chủ được yêu cầu không phù hợp với danh tính ghi trong chứng chỉ.

Khi ghi nhận lỗi, nên lưu tên ứng dụng, phiên bản thư viện TLS, địa chỉ đích, loại proxy và thông báo đầy đủ. Không đưa mật khẩu proxy, token hoặc thông tin xác thực vào nhật ký chia sẻ.

Xác định nguồn gây lỗi SSL khi dùng proxy

So sánh trong cùng điều kiện thực thi

So sánh kết nối trực tiếp và qua proxy bằng cùng ứng dụng, tên miền và môi trường khi chính sách mạng cho phép.

Nếu chính sách mạng cho phép, hãy so sánh kết nối trực tiếp và kết nối qua proxy đến cùng tên miền, bằng cùng ứng dụng và trong cùng môi trường. Nếu kết nối trực tiếp hoạt động nhưng kết nối qua proxy thất bại, cần kiểm tra thêm chứng chỉ được trình bày và cấu hình proxy.

Việc trình duyệt mở được website không chứng minh ứng dụng đã có đủ CA. Trình duyệt, Python, Java và container có thể sử dụng những kho tin cậy khác nhau.

Kiểm tra chứng chỉ thực tế nhận được

Sử dụng công cụ chẩn đoán TLS được tổ chức cho phép để xem chủ thể, đơn vị phát hành, thời hạn và chuỗi chứng chỉ. Với OpenSSL hỗ trợ proxy CONNECT, có thể dùng dạng lệnh openssl s_client -proxy proxy.example:8080 -connect service.example:443 -servername service.example -showcerts.

Đây là ví dụ dành cho HTTP proxy hỗ trợ CONNECT; khả năng xác thực proxy phụ thuộc công cụ. Kết quả hiển thị chứng chỉ không tự chứng minh kết nối hợp lệ, vì công cụ chẩn đoán có thể tiếp tục chạy sau khi báo lỗi xác thực.

Nếu đơn vị phát hành thuộc hạ tầng nội bộ, hãy đối chiếu với bộ phận quản trị. Nếu chứng chỉ không giống cấu hình dự kiến, cần làm rõ trước khi thêm bất kỳ nguồn tin cậy nào.

Lấy và xác thực chứng chỉ CA proxy đúng cách

Chứng chỉ CA proxy cần được nhận qua kênh quản trị chính thức: hệ thống quản lý thiết bị, kho cấu hình nội bộ hoặc bộ phận phụ trách hạ tầng. Không nên tải một chứng chỉ không rõ nguồn gốc rồi cài đặt chỉ để kết nối hoạt động.

Trước khi sử dụng, kiểm tra các thông tin sau:

• Tên chủ thể và đơn vị phát hành phù hợp với tài liệu của tổ chức.
• Thời hạn còn hiệu lực và mục đích sử dụng phù hợp.
• Chứng chỉ có thuộc tính CA theo thiết kế của hạ tầng.
• Dấu vân tay được đối chiếu qua kênh độc lập, đáng tin cậy.
• Tệp có định dạng mà ứng dụng hỗ trợ, chẳng hạn PEM.

Chỉ cần phân phối chứng chỉ công khai; không yêu cầu hoặc sao chép khóa riêng của CA. Cũng không nên mặc định đưa chứng chỉ máy chủ đích vào kho CA để thay thế việc sửa chuỗi tin cậy.

Cấu hình kho tin cậy cho đúng ứng dụng

Kho chứng chỉ của hệ điều hành

Nếu chính sách tổ chức yêu cầu nhiều ứng dụng cùng tin cậy CA nội bộ, quản trị viên có thể phân phối CA vào kho tin cậy hệ điều hành. Trên Linux, quy trình phụ thuộc bản phân phối; trên Windows và macOS, cần chọn đúng phạm vi người dùng hoặc toàn hệ thống.

Tuy nhiên, một số runtime không tự sử dụng kho này. Sau khi cài đặt, vẫn phải kiểm tra ứng dụng đang đọc nguồn CA nào.

CA bundle riêng cho ứng dụng

CA bundle riêng phù hợp khi chỉ một dịch vụ cần tin cậy CA nội bộ. Tệp phải được quản lý tập trung, có quyền truy cập phù hợp và chứa đầy đủ các CA cần cho phạm vi kết nối của ứng dụng.

Nếu thư viện coi bundle tùy chỉnh là nguồn thay thế, một tệp chỉ chứa CA nội bộ có thể khiến kết nối đến các website công cộng thất bại. Cần xác nhận cơ chế của thư viện trước khi triển khai.

Xử lý lỗi CERTIFICATE_VERIFY_FAILED trong Python

Ứng dụng sử dụng Requests

Với Requests, có thể chỉ định đường dẫn CA bundle bằng tham số verify, chẳng hạn requests.get(url, proxies=proxy_config, verify='/app/certs/company-ca-bundle.pem'). Đây là cách cung cấp nguồn tin cậy trong khi vẫn giữ xác minh chứng chỉ.

Biến môi trường REQUESTS_CA_BUNDLE cũng có thể được dùng để chỉ định bundle. Cần bảo đảm tiến trình thực sự nhận biến này; môi trường dịch vụ, tác vụ nền và phiên terminal có thể khác nhau.

Nếu ứng dụng tự tạo luồng xử lý request hoặc Session tùy chỉnh, hãy kiểm tra việc nạp cấu hình môi trường. Không nên suy luận rằng đặt biến ở hệ điều hành là mọi đoạn mã đều sử dụng nó.

Ứng dụng dùng ssl hoặc thư viện khác

Với thư viện chuẩn, có thể tạo ngữ cảnh qua ssl.create_default_context(), sau đó bổ sung CA bằng load_verify_locations(cafile=...). Cách này cho phép nạp thêm CA vào ngữ cảnh đã có thiết lập xác thực mặc định.

Một số thư viện hỗ trợ SSL_CERT_FILE hoặc SSL_CERT_DIR, nhưng hành vi phụ thuộc runtime và cách thư viện khởi tạo TLS. Cần kiểm tra tài liệu tương ứng thay vì áp dụng một biến cho mọi ứng dụng Python.

Không nên chỉnh trực tiếp tệp CA trong thư mục cài đặt thư viện: thay đổi có thể mất khi cập nhật và khó kiểm soát giữa các môi trường.

Lưu ý với curl, Node.js và Java

• curl: tùy chọn --cacert chỉ định CA cho kết nối TLS đến máy chủ đích. Khi dùng HTTPS proxy, --proxy-cacert phục vụ xác thực lớp TLS đến proxy, nếu bản dựng hỗ trợ.
• Node.js: NODE_EXTRA_CA_CERTS có thể bổ sung CA khi khởi động tiến trình. Cấu hình ca được truyền trực tiếp cho kết nối có thể thay đổi nguồn CA được sử dụng.
• Java: cần kiểm tra truststore mà JVM hoặc ứng dụng thực sự dùng. Cài CA vào hệ điều hành không bảo đảm Java tự nhận chứng chỉ đó.

Dù dùng công cụ nào, hãy giữ kiểm tra tên máy chủ và chuỗi chứng chỉ. Việc tin cậy CA không làm cho một chứng chỉ sai tên miền trở thành hợp lệ.

Container và môi trường CI/CD cần được cấu hình riêng

Container và từng bước CI/CD cần được kiểm tra riêng về nguồn CA, đường dẫn tệp và quyền đọc.

Container thường có kho CA độc lập với máy chạy container. Vì vậy, cài chứng chỉ trên máy chủ chưa đủ; image hoặc cấu hình triển khai phải cung cấp CA cho tiến trình bên trong.

Trong CI/CD, cần kiểm tra đường dẫn tệp, quyền đọc, tài khoản chạy và biến môi trường của đúng bước bị lỗi. CA xuất hiện trong bước dựng image không có nghĩa là nó còn tồn tại trong image chạy cuối cùng.

Chứng chỉ CA công khai không phải khóa bí mật, nhưng tính toàn vẹn của nó rất quan trọng. Nên quản lý nguồn cấp, phiên bản và lịch thay thế để tránh sử dụng CA đã hết hạn hoặc không còn được phê duyệt.

Kiểm chứng sau khi sửa cấu hình

Sau khi cập nhật nguồn tin cậy, chạy lại yêu cầu trong chính môi trường từng báo lỗi. Kết quả cần chứng minh kết nối thành công với xác minh TLS vẫn được bật, không chỉ là nhận được phản hồi HTTP.

• Xác nhận chứng chỉ phù hợp với tên miền được yêu cầu.
• Kiểm tra ứng dụng đã đọc đúng bundle hoặc truststore.
• Đối chiếu đơn vị phát hành với thiết kế proxy được phê duyệt.
• Thử các điểm đến cần thiết để phát hiện CA công cộng bị thiếu.
• Trong môi trường kiểm thử được phép, xác nhận ứng dụng vẫn từ chối chứng chỉ không hợp lệ.

Nếu lỗi còn tồn tại, tiếp tục kiểm tra chuỗi trung gian, đồng hồ hệ thống, cấu hình proxy và nguồn CA thực tế. Không bổ sung hàng loạt chứng chỉ chưa được xác thực.

Kết luận

Xử lý lỗi CERTIFICATE_VERIFY_FAILED khi dùng HTTPS qua proxy cần bắt đầu từ việc xác định đúng lớp TLS và nguyên nhân xác thực thất bại. Giải pháp bền vững là sửa chuỗi chứng chỉ, phân phối CA đã được phê duyệt và cấu hình đúng kho tin cậy của ứng dụng.

Khi nguồn tin cậy được quản lý rõ ràng và kết quả được kiểm chứng trong môi trường thực tế, ứng dụng có thể hoạt động qua proxy mà không phải đánh đổi khả năng xác thực danh tính của kết nối HTTPS.