Kịch bản
Bạn đã thiết lập một phân phối (distribution) AWS CloudFront để đứng trước origin của mình—có thể là một máy chủ Nginx trên EC2, một Application Load Balancer (ALB) hoặc một ứng dụng NodeJS tùy chỉnh. Mọi thứ hoạt động hoàn hảo qua HTTP. Tuy nhiên, ngay khi bạn chuyển Origin Protocol Policy sang HTTPS, người dùng của bạn sẽ gặp phải một lỗi gây khó chịu:
502 Bad Gateway: CloudFront was unable to establish a secure connection with the origin server.
Điều này xảy ra khi quá trình bắt tay bảo mật (secure handshake) giữa các edge location của CloudFront và backend của bạn thất bại. Nó không liên quan gì đến chứng chỉ mà người dùng thấy trong trình duyệt của họ. Thay vào đó, sự tin cậy đã bị phá vỡ cụ thể giữa AWS và máy chủ của bạn.
Tại sao CloudFront từ chối kết nối của bạn
CloudFront nổi tiếng là khắt khe với các chứng chỉ SSL. Trong khi một trình duyệt có thể cho phép bạn bỏ qua cảnh báo bằng cách nhấp vào "Tiếp tục", CloudFront chỉ đơn giản là ngắt kết nối để đảm bảo an toàn. Dưới đây là những nguyên nhân thường gặp:
- Chứng chỉ tự ký (Self-signed certificates): CloudFront yêu cầu chứng chỉ từ một Certificate Authority (CA) đáng tin cậy. Nó sẽ không bao giờ tin tưởng một chứng chỉ tự ký cho một custom origin.
- Chứng chỉ hết hạn: Nếu chứng chỉ của bạn hết hạn dù chỉ mới năm phút trước, quá trình bắt tay sẽ thất bại ngay lập tức.
- Chuỗi chứng chỉ bị lỗi (Broken Certificate Chains): Máy chủ của bạn có thể đang gửi chứng chỉ tên miền nhưng lại quên các chứng chỉ trung gian (intermediate certificates). Điều này khiến chuỗi chứng chỉ không hoàn chỉnh.
- Không khớp giao thức (Protocol Mismatch): Máy chủ của bạn có thể chỉ hỗ trợ các giao thức cũ như TLS 1.0, trong khi CloudFront đang tìm kiếm TLS 1.2 hoặc 1.3.
- Không khớp SNI và Hostname: Nếu
Origin Domain Nametrong CloudFront của bạn làorigin.example.com, nhưng chứng chỉ của bạn chỉ bao phủwww.example.com, quá trình bắt tay sẽ thất bại.
Cách khắc phục nhanh: Lối đi "Khẩn cấp"
Nếu trang web của bạn bị sập và bạn cần khôi phục dịch vụ ngay lập tức trong khi tìm lỗi, bạn có thể tạm thời bỏ qua yêu cầu SSL. Chỉ thực hiện việc này như một giải pháp tạm thời.
- Mở CloudFront Console.
- Điều hướng đến Distribution của bạn và nhấp vào tab Origins.
- Chọn origin của bạn và nhấp vào Edit.
- Chuyển Origin Protocol Policy sang "HTTP Only".
- Lưu và đợi phân phối triển khai (thường mất 2–5 phút).
Điều này buộc CloudFront phải giao tiếp với máy chủ của bạn qua cổng 80, bỏ qua hoàn toàn quá trình bắt tay SSL.
Cách khắc phục vĩnh viễn: Giải quyết quá trình bắt tay SSL
1. Kiểm tra chứng chỉ Origin bằng OpenSSL
Đừng đoán mò nữa và hãy xem chính xác máy chủ của bạn đang trình bày gì với thế giới. Chạy lệnh này từ terminal của bạn, thay thế origin.example.com bằng địa chỉ thực tế của backend:
openssl s_client -connect origin.example.com:443 -servername origin.example.com -showcerts
Kiểm tra đầu ra cho hai điều cụ thể:
- Mã trả về xác minh (Verify return code): Bạn muốn thấy
0 (ok). Bất kỳ mã nào khác đều có nghĩa là CloudFront sẽ từ chối kết nối. - Chuỗi chứng chỉ (Certificate chain): Bạn nên thấy ít nhất hai chứng chỉ trong đầu ra—chứng chỉ máy chủ của bạn và chứng chỉ CA trung gian.
2. Đồng bộ hóa Hostname
Một sai lầm phổ biến liên quan đến việc sử dụng tên mặc định do AWS chỉ định. Nếu CloudFront origin của bạn trỏ đến my-load-balancer-12345.us-east-1.elb.amazonaws.com, nhưng chứng chỉ SSL của bạn được cấp cho api.myapp.com, quá trình bắt tay sẽ thất bại. CloudFront yêu cầu chứng chỉ phải khớp chính xác với trường Origin Domain Name.
Để khắc phục điều này, hãy đảm bảo tên miền bạn đã nhập trong cài đặt CloudFront Origin có trong danh sách Subject Alternative Name (SAN) của chứng chỉ.
3. Sửa chuỗi chứng chỉ Nginx hoặc Apache
Nếu bạn đang sử dụng Nginx, chỉ trỏ đến tệp chứng chỉ là không đủ; bạn cần toàn bộ chuỗi (full chain). Đảm bảo chỉ thị ssl_certificate của bạn trỏ đến tệp fullchain.pem (hoặc tương đương) do CA cung cấp.
# Ví dụ cấu hình Nginx
server {
listen 443 ssl;
server_name origin.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Sử dụng các giao thức hiện đại, an toàn
ssl_protocols TLSv1.2 TLSv1.3;
}
4. Kiểm tra các tệp bị lỗi
Tôi đã thấy những trường hợp tệp chứng chỉ bị hỏng trong quá trình chuyển tệp scp thủ công hoặc do một script tự động bị lỗi. Nếu văn bản trông có vẻ đúng nhưng quá trình bắt tay vẫn thất bại, hãy xác minh tính toàn vẹn của tệp.
Tôi thường sử dụng Hash Generator trên ToolCraft để so sánh mã băm SHA-256 của chứng chỉ cục bộ với chứng chỉ trên máy chủ. Vì nó xử lý tệp cục bộ trong trình duyệt của bạn, bạn không phải tải các khóa nhạy cảm lên máy chủ bên thứ ba. Nếu các mã băm không khớp, tệp của bạn đã bị hỏng trong quá trình tải lên.
Cách xác minh việc khắc phục
CloudFront lưu bộ nhớ đệm cho các phản hồi 502 trong 10 giây theo mặc định. Hãy đợi một lát sau khi thay đổi máy chủ trước khi kiểm tra lại. Bạn có thể sử dụng curl để kiểm tra trực tiếp phân phối trong khi buộc sử dụng đúng Host header:
curl -I https://your-id.cloudfront.net -H "Host: your-public-domain.com"
Thành công sẽ hiển thị 200 OK. Nếu bạn vẫn thấy 502, hãy kiểm tra header X-Cache. Nếu nó ghi Error from cloudfront, quá trình bắt tay vẫn là điểm nghẽn.
Danh sách kiểm tra cuối cùng
- Đã được ký bởi CA chưa? (Không cho phép chứng chỉ tự ký).
- Chuỗi chứng chỉ có đầy đủ không? (Phải bao gồm các chứng chỉ trung gian).
- Hostname có khớp không? (Trường Origin Domain Name phải khớp với Cert CN/SAN).
- Cổng có đang mở không? (Đảm bảo Security Group của bạn cho phép cổng 443 từ các dải IP của CloudFront).