무엇을 도와드릴까요?
어떤 인증서를 선택할지부터 주문·인증·다운로드·설치·갱신까지.
궁금한 주제를 선택하거나 증상과 키워드로 검색하세요.
전체 FAQ
60개의 도움말Apache에 SSL 인증서를 적용하려면 무엇을 확인하나요?
Apache 2.4에서는 mod_ssl, 443 리스너와 대상 VirtualHost를 확인합니다. SSLEngine on, SSLCertificateFile, SSLCertificateKeyFile에 올바른 파일을 지정하고 ServerName이 운영 도메인과 일치하게 구성하세요.
서버 인증서와 필요한 중간 인증서, 개인키의 대응 관계와 읽기 권한을 점검합니다. 설정·파일을 백업하고 apachectl configtest(환경에 따라 httpd -t)를 실행한 뒤 정상일 때만 반영하세요.
여러 도메인에 서로 다른 인증서를 사용할 수 있나요?
도메인별 HTTPS VirtualHost와 SNI를 구성할 수 있습니다. 각 호스트에 정확한 ServerName·ServerAlias와 인증서 경로를 지정하세요.
같은 IP의 기본 가상 호스트가 잘못 응답하지 않는지 도메인별로 확인합니다. 서버 IP로만 시험하지 말고 실제 호스트 이름을 사용하세요. 각각의 접속 이름이 해당 인증서의 SAN에 포함되어야 합니다.
인증서를 바꾼 뒤 Apache가 시작되지 않습니다.
재시작을 반복하기 전에 문법 검사 결과와 오류 로그를 확인하세요. 파일 경로 오타, 개인키 불일치, 읽기 권한, 암호화된 개인키의 비밀번호 입력 문제를 구분해야 합니다.
새 설정이 실패하면 기존 정상 설정을 기준으로 차이를 확인합니다. 파일 전체 권한을 열어 해결하지 말고 서비스 계정에 필요한 권한만 부여하세요. 수정 후 문법 검사가 통과하면 반영하고 외부 HTTPS를 확인합니다.
Nginx에는 어떤 인증서 파일을 설정하나요?
대상 HTTPS server 블록의 ssl_certificate에는 서버 인증서가 먼저, 필요한 중간 인증서가 뒤에 오는 PEM 체인을 지정합니다. ssl_certificate_key에는 대응하는 개인키 파일을 지정하세요.
server_name과 리스너를 확인하고 nginx -t로 문법·파일 오류를 검사합니다. 통과한 뒤 설정을 reload하고 실제 도메인으로 검증하세요. 개인키를 웹 공개 폴더에 두거나 불필요하게 접근 권한을 넓히지 마세요.
PC에서는 되는데 일부 기기에서 인증서 오류가 납니다.
서버가 중간 인증서를 빠뜨리면 이를 이미 저장한 PC에서는 정상처럼 보이고 다른 기기에서는 신뢰 오류가 날 수 있습니다. ssl_certificate 파일에 서버 인증서 다음으로 필요한 중간 인증서가 연결되어 있는지 확인하세요.
체인을 수정한 뒤 설정을 검사·반영하고 서로 다른 기기에서 다시 확인합니다. 문제가 특정 오래된 기기에만 남으면 TLS 지원과 루트 저장소 상태도 확인하세요. 루트 인증서 파일을 무작정 덧붙이는 것이 해결책은 아닙니다.
인증서를 교체했는데 이전 인증서가 보입니다.
현재 실행 중인 Nginx가 사용하는 설정 파일과 server_name, ssl_certificate 경로를 확인하세요. 같은 이름의 다른 설정이나 심볼릭 링크가 이전 파일을 가리킬 수 있습니다.
nginx -t가 성공하면 reload하고 새 연결로 인증서를 확인합니다. 계속 이전 인증서가 보이면 DNS의 다른 IP, CDN·로드밸런서, 여러 서버 중 미교체된 장비를 확인하세요.
IIS에서 인증서를 설치한 뒤 무엇을 해야 하나요?
IIS 관리자에서 서버 인증서를 등록한 다음 대상 사이트의 ‘바인딩’에서 https, IP·포트·호스트 이름과 사용할 인증서를 지정하세요. 서버에 인증서를 가져왔다는 것만으로 사이트에 자동 연결되지는 않습니다.
여러 사이트가 같은 IP·포트를 공유하면 SNI와 호스트 이름을 점검합니다. 변경 후 외부에서 실제 도메인으로 접속해 선택한 인증서와 만료일이 표시되는지 확인하세요.
IIS HTTPS 바인딩 목록에 인증서가 나타나지 않습니다.
인증서가 로컬 컴퓨터의 적절한 인증서 저장소에 있는지, 대응하는 개인키가 연결되어 있는지 확인하세요. CSR을 생성한 서버에서 요청 완료 절차를 진행했는지도 점검합니다.
다른 서버로 옮기는 경우 원본에서 개인키를 포함한 PFX 내보내기와 가져오기가 필요할 수 있습니다. 개인키가 없는 CER 파일만 복사해서는 해결되지 않습니다. PFX와 암호는 별도 안전한 경로로 관리하세요.
인증서를 교체했는데 사이트가 기존 인증서를 사용합니다.
대상 사이트의 HTTPS 바인딩을 열어 새 인증서가 선택되어 있는지 확인하세요. 유사한 이름의 인증서가 많으면 지문과 만료일로 구분합니다.
동일 IP·포트의 다른 사이트, SNI 호스트 이름, 앞단 로드밸런서를 함께 점검하세요. 바인딩 변경 후 외부 HTTPS 연결을 확인하고, 모든 사용처가 전환되기 전에 기존 인증서를 삭제하지 마세요.
Tomcat에 직접 SSL을 설치해야 하나요?
브라우저 앞단의 Nginx·Apache·IIS·로드밸런서가 TLS를 종료한다면 외부용 인증서는 먼저 그 장비에 적용합니다. Tomcat에만 설치해도 브라우저에 보이는 인증서가 바뀌지는 않습니다.
Tomcat이 HTTPS를 직접 제공하면 SSL Connector를 구성합니다. 앞단에서 Tomcat까지도 암호화할지는 서비스 구조에 따라 별도로 결정하고, 리디렉션과 프록시 헤더 처리도 점검하세요.
Tomcat에서 사용할 인증서 저장 형식은 무엇인가요?
Tomcat은 구성과 SSL 구현체에 따라 PKCS12·JKS 같은 키 저장소 또는 PEM 파일 방식으로 인증서를 설정합니다. 키 저장소에는 개인키 항목과 서버 인증서·중간 인증서 체인이 연결되어 있어야 합니다.
파일 확장자만 바꾸지 말고 실제 형식, 별칭(alias), 저장소·키 암호와 서비스 계정 권한을 확인하세요. 공개 인증서만 있는 trusted certificate 항목은 서버 서명용 개인키 항목을 대신하지 못합니다.
Tomcat SSL Connector가 정상 동작하지 않습니다.
server.xml의 대상 Connector, SSLHostConfig와 Certificate 설정이 사용 버전·SSL 구현 방식에 맞는지 확인하세요. 키 저장소 경로, 암호, 별칭과 개인키 포함 여부를 로그와 대조합니다.
설정을 백업한 뒤 테스트 환경에서 기동을 확인하고, 포트 충돌·방화벽·앞단 프록시도 점검하세요. 예제 포트를 그대로 외부에 노출하거나 해결을 위해 키 저장소 암호를 코드 저장소에 올리지 마세요.
AWS ALB에서는 인증서를 어디에 연결하나요?
ALB의 HTTPS 리스너에 인증서를 연결합니다. 외부에서 발급받은 인증서는 필요한 서버 인증서·개인키·체인을 ACM에 가져온 뒤 ALB와 같은 리전의 인증서를 선택합니다.
리스너 포트, 보안 정책, 대상 그룹과 보안 그룹을 확인하세요. 원본 웹서버의 인증서를 바꾸는 것만으로 ALB의 인증서가 바뀌지 않습니다. 실제 도메인으로 외부 연결을 시험합니다.
ALB에 여러 도메인 인증서를 연결할 수 있나요?
HTTPS 리스너의 인증서 목록에 여러 인증서를 연결할 수 있습니다. SNI 요청에 맞는 인증서가 선택되며, 기본 인증서도 정확히 설정해야 합니다.
각 도메인의 DNS 연결과 인증서 SAN을 확인하고 실제 호스트 이름별로 시험하세요. 목록에 인증서가 있어도 이름이 맞지 않거나 다른 리스너로 접속하면 기대한 인증서가 제공되지 않을 수 있습니다.
로드밸런서의 인증서를 갱신할 때 무엇을 확인하나요?
외부 발급 인증서를 ACM에 가져온 경우 ACM이 그 인증서를 자동 갱신해 주지는 않습니다. 새 인증서를 준비해 재가져오기 또는 리스너 인증서 교체를 진행해야 합니다.
기본 인증서뿐 아니라 SNI 목록과 다른 리스너·리전의 사용처도 점검하세요. 교체 후 외부 접속의 만료일·체인·이름을 확인합니다. 원본 서버까지 HTTPS를 사용한다면 그 구간의 인증서도 별도로 관리해야 합니다.
주문번호·도메인·진행 단계와 오류 내용을 알려 주세요.
개인키·비밀번호·인증 코드 등 비밀 정보는 보내지 마세요.