Amazon CloudFront: 502 Bad Gateway시 Origin SSL 인증서 설정에 대하여

Published in

Cloud Villains

6 min readJun 24, 2021

⚠️ 2021. 6. 25 업데이트
이번 포스트 작성하던 시기에는 테스트 결과를 TCP패킷으로 전부 확인 했었습니다. 글이 올라가고 난 뒤에 몇몇 질문을 받게 되어 재검증을 위해 동일한 환경으로 다시 테스트한 결과가 포스트 내용과 달라 업데이트 하였습니다.
현재는 글을 작성하던 시기와는 다르게, 현재 가이드와 같이 Origin Domain Name 또는 Host 중 하나라도 Origin의 SSL 인증서와 일치하면 문제가 생기지 않습니다.

비오던 어느날..

CloudFront에서 Origin으로 SSL Handshake를 어떻게 하고 있을까? 라는 생각에 Origin request 동작을 들여다 보게 되었습니다. 그러던 중 인증서가 맞게 설정되어 있는데도 CloudFront에서 502 Bad Gateway 응답을 받게 되었습니다. 이를 해결하기 위해 공식 가이드 내용을 보았는데 잘 이해가 안되는 부분이 있어서 자세히 확인해 보았습니다.

CloudFront 설정

Distribution setting에서 Alternate Domain Name으로 test.megazone.cf를 사용 합니다. 그리고 미리 준비해둔 ACM *.megazone.cf을 Custom SSL Certificate로 지정 해줬습니다.

즉, test.megazone.cf를 CloudFront의 서비스도메인으로 사용합니다.

Origin setting은 Custom origin으로 Domain org.hedy.kim을 사용 하였습니다.

Origin server “org.hedy.kim”은 NGINX를 사용하였으며, 설정은 아래와 같이 하였습니다.

server {
    listen 443 ssl;
    server_name _;    # SSL Certificate
    ssl_certificate /certs/fullchain.pem;
    ssl_certificate_key /certs/privkey.pem;
    
    root /var/www/html/;
    index index.html;
}

Behavior 설정에서는 Cache Policy와 Origin Request Policy는 아래와 같이 Viewer request header 모두를 Origin으로 전달 하고, 모든 응답을 Cache하지 않도록 하였습니다.

CloudFront Default Cache Behavior Settings

In My Dreams..

여기까지 설정에 대한 예상 흐름은 아래와 그림과 같이

Viewer와 CloudFront 사이에는 ACM 인증서 *.megazone.cf이 사용되고, CloudFront와 Origin server “org.hedy.kim” 사이에는 CA기관 발급 인증서 *.megazone.cf를 사용되어 아름답게 응답 프로세스가 진행 될 것 같았습니다.

현실..

⚠️ 2021. 6. 25 업데이트
글을 작성하던 시기와는 다르게, 현재 가이드와 같이 Origin Domain Name 또는 Host 중 하나라도 Origin의 SSL 인증서와 일치하면 문제가 생기지 않습니다.

하지만, 실제 응답은…

AWS Document의 설명을 읽고 고민해 보았습니다.
https://docs.amazonaws.cn/en_us/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html#ssl-negotitation-failure

특히 이 문장

To determine whether domain names in the certificate match the Origin Domain Name in the distribution or the Host header, you can use an online SSL checker or OpenSSL.

Origin Domain Name 또는 Host 헤더가 인증서의 도메인과 일치되어야 한다는 것인데, CloudFront에서 Origin으로 요청하는 SNI와 Host 헤더 보다도 Origin Domain Name의 설정 값이 우선시 되는 것으로 보입니다. 그래서 실제 동작은 아래 그림과 같이

SNI와 Host 헤더는 Origin 인증서에 일치(Match) 되지만, Origin Domain Name “org.hedy.kim”과는 일치되지 않아 유효하지 않는 것으로 처리 되어 502 응답 됩니다.

결국에는..

설정되어 있는 Origin Domain Name “org.hedy.kim”과 일치하는 인증서 *.hedy.kim으로 변경 후 최종 정상 응답을 받을 수 있는 것을 확인 할 수 있었습니다.

SNI와 Host 헤더는 Origin server에서 필터링 할 때 사용하는 것 외에는 SSL 인증서 유효성 검증에는 영향이 없는 것으로 보입니다.

⚠️ 2021. 6. 25 업데이트
글을 작성하던 시기와는 다르게, 현재 가이드와 같이 Origin Domain Name 또는 Host 중 하나라도 Origin의 SSL 인증서와 일치하면 문제가 생기지 않습니다.

마치며..

사실 Origin Domain Name과 Origin 인증서 모두 CloudFront에 사용 하는 서비스 Domain(FQDN)과 동일한 Root domain(e.g example.com)으로 설정한다면 문제는 없겠지만, 하나의 Origin에 여러 도메인을 Virtual Host를 설정하여 사용하고 Origin 도메인을 하나로만 사용하게 된다면 이와 같은 혼란을 누군가는 겪게 되지 않을까 하여, 그런 어려움을 겪을 미래의 누군가에게 이 글이 도움이 되었으면 합니다.

.fin

Cloud Villains Facebook Page를 팔로우하시면 새로 발행되는 글의 알람을 더욱 손쉽게 받아보실 수 있습니다.