
GET https://api.co-kkiri.com/my-page/info net::ERR_CERT_COMMON_NAME_INVALID
원인을 찾는데 애를 조금 먹었다. 왜냐하면 바꾼 것이 너무 많았기 때문이다.
캐시는 당연히 삭제해봤고
ssl인증서를 받고 nginx에 제대로된 경로를 지정하지 않은 줄 알고, 이동시키고 다시 reload도 해봤다.
pm2도 재시작해보고
nginx도 재시작해봤다
브라우저 캐시도 삭제해봤다.
그러던 중
SSL 관련하여 무료로 테스트 해주는 사이트를 발견했다
Qualys SSL Labs
이 곳에서 Hostname에 우리 api 도메인을 작성하고 테스트를 진행했다
그랬더니 충격적인 결과가 나왔다

전혀 생각도 못한 문제가 원인이었다.
분명 certbot --nginx -d api.co-kkiri.com으로 받았던 인증서가 도메인이 우리 프론트엔드 도메인이름으로 되어있는 것이었다..
같은 인스턴스에서 여러번 발급을 받으면서 실수를 했거나, 문제가 생긴듯 싶다.
이 중 1,3번에 문제가 발생한 듯 했다.
www.dev.co-kkiri.com
이 도메인의 경우에는, 내가 하나의 server 블록 내에 여러개의 ssl_certificate을 지정하며 발생했다.
nginx는 하나의 서버 블록 내에서 여러개의 ssl_certificate를 인식하지 못한다고 한다(나의 무지...)
하지만 나는 이렇게 처리를 했던 것이다.
ssl_certificate <dev.co-kkiri.com 경로>;
ssl_certificate_key <dev.co-kkiri.com 경로>;
ssl_certificate <www.dev.co-kkiri.com 경로>;
ssl_certificate_key <www.dev.co-kkiri.com 경로>;
이렇게 하면 설정에서 두 개의 인증서를 모두 기록하면, Nginx는 마지막에 지정된 인증서만 사용하기 때문에, 테스트시 인증서에 대한 도메인이 www.dev.co-kkiri.com 라고 인식했던 것이다.
frontend관련 nginx config 파일을 아래와 같이 한 파일 내에 도메인별로 분리하여 작성해 해결했다
server {
listen 443 ssl;
listen [::]:443 ssl;
keepalive_timeout 70;
ssl_certificate <dev.co-kkiri.com 경로>;
ssl_certificate_key <dev.co-kkiri.com 경로>;
server_name dev.co-kkiri.com;
location / {
root <파일 경로>;
index <파일 경로>;
}
}
server {
listen 443 ssl;
listen [::]:443 ssl;
keepalive_timeout 70;
ssl_certificate <www.dev.co-kkiri.com 경로>;
ssl_certificate_key <www.dev.co-kkiri.com 경로>;
server_name www.dev.co-kkiri.com;
location / {
root <파일 경로>;
index <파일 경로>;
}
}


이 친구의 문제는 조금 더 까다롭다.
위의 문제를 해결하니 이번에는 dev.co-kkiri.com의 인증서를 들고오는 문제가 발생했다.

nginx가 conf 파일을 인식하는 과정 혹은 SSL 핸드 셰이크를 하는 과정에서 문제가 발생한 것 같았다.
이에 대해 해결하는 과정은 다음 글에서 후술하겠다.