CSR 생성
Q1. 인증서 갱신시, CSR파일을 전에 사용하던 것으로 가능한가요?
CSR 재사용 정책은 인증기관별로 상이합니다.
GlobalSign CA의 경우, CSR 재사용이 금지되어있으며
다른 CA의 경우도 보안상의 이유로 CSR 재사용을 권장하지 않습니다.
Q2. KEY파일을 삭제한 경우에는 어떻게 해야 하나요?
KEY파일은 웹 서버 내에 보관되어져 있는 고객의 개인키로서, 인증 기관은 그에 대한 어떠한 정보도 가지고 있지 않으며 가지고 있어서도 안되는 파일입니다.
인증서는 고객이 웹 서버에서 생성하신 개인키와 쌍이 되는 공개키를 인증 기관에 보냈을 때, 이를 인증 기관에서 심사하여 전자 서명을 해주는 파일입니다.
고객이 개인키를 가지고 있지 않은 경우에는 인증서는 제 기능을 할 수 없습니다.
이 경우에는 인증서를 교체하셔야 합니다.
Q3. 발급받은 SSL 인증서 정보를 변경할 수 있나요?
한 번 발급 받은 인증서는 인증서 표시 정보 또는 웹 서버 변경, 도메인 변경 등이 있더라도 변경 및 재발급이 불가능합니다.
불가능한 이유는 인증서 발급 신청 시 입력했던 CSR 코드에는 해당 웹 서버, 도메인 및 기타 입력 정보를 토대로 변경 불가한 고유한 암호화 코드를 생성하기 때문입니다.
이 암호화 코드를 SSL 인증 서버에 등록 및 발급 하게 되며, 발급된 인증서가 설치된 웹사이트의 암호화 위/변조 여부를 인증서를 통해서 웹사이트의 방문자에게 확인을 해줍니다.
그러므로 정보 변경 또는 도메인과 다른 인증서가 웹 서버에 설치 되는 등 어느 부분이라도 발급 된 인증서와 SSL에 등록된 정보가 다를 경우에는 웹 브라우저에 경고창이 뜨게 됩니다.
인증서 신청 시 생성하는 CSR 정보 입력 시 매우 주의하여 생성 하셔야 합니다.
프로토콜
Q1. TLS1.0, TLS1.1을 제약하는 이유는 무엇인가요?
TLS의 초기 버전인 TLS1.0, TLS1.1은 POODLE 및 BEAST와 같은 다양한 공격에 취약하며 프로토콜 취약점으로 인한 세션 하이제킹이 발생할 수 있습니다.
•
POODLE(Padding Oracle On Downgraded Legacy Encryption) 취약점
구식 암호화 기법을 악용할 수 있게 하는 프로토콜 다운그레이드 취약점
•
BEAST(Browser Exploit Against SSL/TLS) 취약점
클라이언트 브라우저에서 HTTPS의 쿠키들을 해독하고 효과적인 타킷의 세션을 하이제킹할 수 있는 취약점
Q2. TLS 1.0, 1.1이 중단 되면 사용자들에게 어떤 영향이 있나요?
지원이 중단되면 해당 프로토콜만 사용 시
최종 클라이언트들은 HTTPS로 접속이 불가한 경우가 발생되며 서비스에 영향을 줄 수 있습니다.
Q3. 인증서에 따라 프로토콜 버전이 다른가요?
인증서는 프로토콜 버전을 조정하거나 제약할 수 없습니다.
프로토콜은 오직 서버 설정 및 사양에 따라 이루어집니다.
마찬가지로 발급에 따라서 TLS 용 인증서가 따로 있지는 않습니다.
Q4. 서버에서는 적용이 확인이 되었는데 SSL LABS에서는 TLS1.2가 비활성화 되어 있습니다.
서버에서는 적용이 확인이 되었지만, 클라이언트나 SSL LABS에서는 활성화가 되지 않은 것을 확인할 수도 있습니다.
이는 망 구성도에서 웹 방화벽이 존재할 경우 나타날 수 있습니다.
서버에서는 바뀌었지만, 클라이언트 같은 외부 접속자는 웹 방화벽을 거치게 되므로 웹 방화벽 장비의 설정을 볼 수도 있습니다.
Q5. 설정 적용 후의 주의 사항이 있나요?
프로토콜 적용 후에는 어떤 서버이든 재시작이 필요합니다. 다만, IIS를 제외한 서버는 웹 서버만 재시작을 하면 됩니다.
IIS 같은 경우 레지스터리를 수정해야 함으로 서버 자체를 재시작 해야 합니다.
적용 후 확인 방법은
보통 리눅스 계열의 경우 서버에서 아래의 명령어로 확인이 가능합니다.
openssl s_client -connect 127.0.0.1:443 -tls1_2
Plain Text
복사
위 명령어로 CONNECTED(00000003) 이 확인이 되면 됩니다.
Webtob의 경우는 아래의 명령어로 확인 가능합니다.
wbssl s_client -connect 127.0.0.1:443 -tls1_2
Plain Text
복사
그 밖에는 아래의 사이트에서 TLS 적용을 확인 할 수 있습니다.
사이트에 접속 후 아래의 방법대로 진행하시면 됩니다.
1.
Test your server 클릭
2.
도메인을 입력
3.
지원되고 있는 버전 확인
Q6. TLS 1.2를 적용하기 위한 기본 사양이 어떻게 되나요?
Q7. 프로토콜 조정이 필요한데 인증서를 재발급 받아야 하나요?
프로토콜에 경우 인증서와는 무관하게 웹 서버 버전과 Openssl, Java 버전과 관련이 있습니다.
위 버전이 낮을 경우 TLS 1.2 지원이 불가 할 수 있습니다.
Q8. 프로토콜 적용 전 주의 사항이 무엇인가요?
아래와 같이 주의사항에 대해 말씀드립니다.
1.
아파치, Nginx, Webtob 등의 경우 프로세스 재시작으로 적용이 가능합니다.
(IIS의 경우 서버 전체를 재시작해야 합니다.)
2.
설정이 잘못되었을 경우 재시작을 해도 가동되지 않을 수 있습니다. 사전에 백업 설정 파일을 만드셔야 합니다.
3.
프로토콜 적용 후에 낮은 사양의 OS를 사용하는 고객은 접속이 불가할 수 있습니다.
4.
높은 버전의 프로토콜 및 알고리즘의 경우 웹 서버 사양을 확인하셔야 합니다.
(버전의 경우 일부 회원에 한하여 가이드를 제공합니다.)
Q9. 프로토콜 적용을 하고 어디서 확인을 할 수 있나요?
프로토콜의 경우 아래의 URL에서 확인이 가능합니다. 단, 443 포트일 경우에만 확인이 가능합니다.
1.
2.
도메인을 기재
3.
프로토콜 결과를 확인
TLS/SSL 인증서
Q1. ssl 인증서 특정 페이지만 적용 가능한가요 ?
네, 개발 소스 부분에서 로그인 페이지만 적용 가능합니다.
Q2. 웹 서버 변경시 ssl 인증서 확장자 변경해서 사용 가능한가요? -cer, crt, pem
네, 다만 변환을 위해서는 openssl이 필요하며 openssl은 서버에서 기본적으로 내장되어 있는지 확인이 필요합니다. 또한 Java의 Keytool이 필요합니다. 명령어는 아래와 같습니다.
[PEM 파일 -> PFX]
openssl pkcs12 -inkey ucert_key -in ucert_cert.pem -export -out tantansteel.pfx
[PFX → PEM]
openssl pkcs12 -in [PFX] -nokeys -out [인증서] openssl pkcs12 -in [PFX] -nocerts -nodes -out [개인키]
[PFX → jks]
keytool -importkeystore -srckeystore uecrt.pfx -srcstoretype PKCS12 -destkeystore ucert.jks
[jks → PFX]
keytool -importkeystore -srckeystore keystore.jks -srcstoretype JKS -deststoretype PKCS12 -destkeystore keystore.pfx
[crt → der]
openssl x509 -in example.crt -out openssl.der -outform DER
[der → crt]
openssl x509 -in openssl.der -inform DER -out openssl.pem -outform PEM
Q3. 발급받은 인증서로 중복으로 다른 서버에 적용 가능한가요?
인증서는 서버 라이센스에 영향을 받지 않고, 도메인만 동일하다면 무제한으로 설치가 가능합니다.
Q4. pass.sh/pass.bat 는 어떻게 만드나요?
[리눅스]
vi conf/pass.sh #!/bin/shecho “패스워드” :wq chmod 700 pass.sh
[윈도우]
1. 메모장 열기 2. 아래 내용 기재@echo password3. 다른 이름으로 저장pass.bat
Q5. 인증서의 통신 과정을 알고 싶습니다.
1. 통신 개시 : 클라이언트(웹 브라우저)가 웹 서버에 접근
2. 서버 인증서 전송 : 웹 서버는 서버 인증서를 클라이언트로 전송
3. 서명 확인 : 서버 인증서를 받은 클라이언트는 루트 인증서를 사용해 서명을 확인하고 서버의 신뢰성 확인
4. 암호 알고리즘 통지 : 클라이언트는 자신이 사용 가능한 암호 알고리즘 종류를 서버에 통지
5. 암호 알고리즘 선정 : 서버는 클라이언트와 송수신 가능한 암호 알고리즘 선택
6. 공개 키 획득 : 클라이언트는 암호 통신용 공개 키를 생성해 서버 인증서 내의 서버 공개 키를 사용해 암호화
7. 공개 키 생성 : 클라이언트는 공개 키를 서버에 전달하고 서버는 자신의 비밀(개인) 키를 사용해 공개 키를 복호화
8. 암호화 통신 : 공개 키를 사용해 암호화 통신을 개시
Q6. 인증서를 발급 받았는데 루트 인증서 알고리즘을 바꿀 수 있나요?
루트 인증서의 알고리즘은 인증기관에서 정한 알고리즘이라 변경이 불가합니다. 다른 상품으로 이전하여 변경하실수 있습니다.
Q7. 윈도우 및 리눅스에서 방화벽 오픈하는 방법이 무엇인가요?
윈도우 : 시작 - 제어판 - 방화벽 - 왼쪽 고급설정 - 인바운드 규칙 - 오른쪽 새규칙 설정 리눅스 :
iptables -I INPUT -p tcp --dport (포트번호) -j ACCEPT (Centos 6) firewall-cmd --permanent --zone=public --add-port=(포트번호)/tcp (Cenots 7)
Q8. JAVA keystore에 인증서를 추가하고 싶은데 가능한가요?
keytool을 이용하여 추가하실수 있습니다. 명령어는 아래와 같습니다.${JAVA_HOME}/bin/keytool -importcert -trustcacerts -keystore ${JAVA_HOME}/lib/security/cacerts -file ${JAVA_HOME}/lib/security/[인증서 파일명] -alias [인증서_별칭]
Q9. 인증서 알고르즘은 RSA 알고리즘 말고 다른 알고리즘이 있나요?
현재 인증서 알고리즘은 발급가능한 기준으로 RSA와 ECC 알고리즘이 있습니다.
Q10. 인증서 형식 변환시 대소문자를 가리나요?
파일변환 시 대소문자를 가립니다. 하위옵션이 소문자로 되어있으면 소문자로 입력하셔야 올바른 명령어로 처리될 수 있습니다.
Q11. 인증서에 멀티인증서인지 어떻게 확인할 수 있나요?
CRT 형식의 인증서에서 "자세히" 탭에 "주체대체이름"을 클릭하여 멀티 인증서인지 확인 하실 수 있습니다.
Q12. SSL 포트번호 사용범위가 어떻게 되나요?
포트는 1 ~ 65535 까지 있으며 1 ~ 1023은 root 권한으로만 port를 열 수 있는 예약영역이며 이 영역안에 https 디폴트 포트인 443이 속해있습니다. 443 외에 SSL 포트를 사용하고 싶다면 1024 ~ 49151 범위 안으로 포트 사용을 권장합니다.
참고로 시스템 포트(well-known port) 및 등록된 포트(registered port)는 전송프로토콜(TCP,UDP 등)에서 응용 프로그램 또는 서비스를 나타내는데 사용 되고,동적포트(dynamic port)는 어느 프로그램에서나 사용할 수 있는 포트 입니다.
0 ~ 1023 : 시스템 포트 (well-known port)
1024 ~ 49151 : 등록된 포트 (registered port)
49152 ~ 65535 : 동적포트 (dynamic port)
Q13. 인증서 작업 후 바로 적용이 되는건가요?
인증서 신규 및 갱신 작업 후에는 웹서버를 재시작 해주어야 합니다. 그러나 IIS는 인증서 작업이 실시간으로 반영이 되어 따로 재 시작이 필요 없지만, 인증서가 잘못 적용 된 경우에는 IIS가 정지되어 서비스에 영향이 미칠 수 있으니, 참고 해 주시기 바랍니다.
Q14. 프로세스는 재기동을 했는데 사이트에서 https 연결이 안 됩니다.
1.서버 내 인증서 정상 적용 확인 openssl s_clinet –connect localhost:443 | openssl x509 -dates
2. 인증서 포트 방화벽 오픈 확인 인증서 포트가 방화벽이나 네트워크단에서 오픈 되어 있는지 확인 해 주시기 바랍니다.
Q15. 웹서버 버전별로 적용해야하는 인증서가 다른가요?
인증서는 웹서버 버전에 영향을 받지 않습니다. 어느 웹서버 버전이든 모두 설치가 가능합니다.
Q16. 인증서 파일을 crt 3개와 key 파일 1개를 받았습니다. 각각 역할이 있나요?
인증서 파일은 기본적으로 4개의 파일을 구성으로 배포가 됩니다.[도메인 인증서, 체인(Chain) 인증서, 루트(Root CA) 인증서, 키]
인증서는 계층 구조로 인증을 받게 됩니다.실제 인증서 파일의 인증경로를 보면 아래와 같습니다. 받으신 인증서 파일들은 각각 위와 같이 연결 구조로 인증을 진행합니다. 만약 위 구조에 어긋나거나 설치과정에서 누락이 있을 경우 안드로이드 모바일 혹은 PC에서 인증서 오류가 발생할 수 있습니다.
[Chain & Root CA] [GlobalSign] 인증기관 구분 인증서 형식 Chain GLOBALSIGN_RSA_DV_SSL_CA_2018 [DV] GLOBALSIGN_RSA_OV_SSL_CA_2018 [OV] GLOBALSIGN_EXTENDED_VALIDATION_CA__SHA256__G3 [EV] ALPHASSL_CA__SHA256__G2 [Alpha] Root CA GLOBALSIGN GLOBALSIGN_ROOT_CA [comodo] 인증기관구분인증서 형식 Chain SECTIGO_RSA_DOMAIN_VALIDATION_SECURE_SERVER_CA Root CA USERTRUST_RSA_CERTIFICATION_AUTHORITY [Digicert] 인증기관구분인증서 형식 Chain THAWTE_RSA_CA_2018 Root CA DIGICERT_GLOBAL_ROOT_CA
Q17. 싱글 인증서를 여러 개 구매하였는데 도메인들에 대하여 같은 포트로 사용이 가능한가요?
기본적으로 같은 포트에는 서로 다른 인증서를 적용할 수 없습니다. 포트를 구분하여 적용하거나 멀티 인증서로 재발급 받으시면 같은 포트로 사용 가능합니다.
Q18. 웹 서버별 인증서 형식을 알 수 있을까요?
웹 서버별 인증서 형식은 아래의 표를 참조하시기 바랍니다.
서버 형식 비밀번호
•
Apache
◦
crt, key (패스워드 제거가능)
◦
pem, key (패스워드 제거가능)
•
NginX
◦
crt, key (패스워드 제거가능)
◦
pem, key (패스워드 제거가능)
•
Lighttpd
◦
pem, key (패스워드 제거가능)
•
Webtob
◦
crt, key (패스워드 제거가능)
•
Tomcat
◦
jks (패스워드 6자이상, 제거불가)
•
Resin
◦
pem, key (패스워드 제거가능)
◦
jks (패스워드 6자이상, 제거불가)
•
WebLogic
◦
jks (패스워드 6자이상, 제거불가)
•
IIS
◦
pfx (패스워드 4자이상, 제거불가)
•
Websphere
◦
kdb, sth (패스워드 6자이상, 제거불가)
•
IHS(IBM HTTP Server)
◦
kdb, sth (패스워드 6자이상, 제거불가)
•
OHS(Oracle HTTP Server)
◦
sso (패스워드 4자이상, 제거불가)
•
Lotus Domino
◦
kyr (패스워드 6자이상, 제거불가)
•
웹방화벽
◦
pfx, pem (패스워드 6자이상, 제거불가)
◦
IPLANET db (패스워드 8자이상, 제거불가)
Q19. IP가 변경이 되었는데 발급 받은 인증서를 그대로 적용 가능한가요?
인증서는 일반적으로 도메인을 기준으로 발급이 됩니다. 따라서 서버 이전 혹은 서버 증설이 되더라도 기존 인증서를 사용하여도 도메인만 동일하다면 사용하셔도 무방하나,인증서 발급 시 GlobalSign IP 인증서를 발급 받으신 경우, 인증서 도메인 수정 및 환불 정책에 따라 인증서 발급일로부터 30일 이내에는 IP 수정이 무료이지만, 30일이 지났을 경우 신규구매가 이루어져야 합니다.
Q20. 인증서 발급을 위한 메타/해시 데이터 올릴 때 해당 .txt 파일 내용 값이 보이지 않아요.
해당 체크리스트를 참조하여 확인이 필요 합니다.
•
홈페이지에 지정된 home directory에 업로드가 되었는가?
•
디렉토리 리스팅에 포함되어 있는가?
•
txt파일을 바라보지 못하게 세팅이 되어있다.
•
해외 방화벽이 실행중인가?
•
url 뒤에 포트번호가 기재되어 있는가?
Q21. [인증서문의] Web-Was 연동일 경우 어느 서비스에 인증서를 설치해야 하나요?
인증서는 WEB 혹은 WAS 둘중에 원하시는 프로세스에 설치를 해주시면 됩니다. 다만, 보통의 경우 WEB에 설치를 진행하며 80포트를 이용하는 웹서버에 주로 설치를 진행합니다.
Q22. server.xml 파일에 리다이렉트 설정을 하면 인증서에 포함되지 않은 도메인까지 리다이렉트가 됩니다.
인증서를 멀티 인증서를 구매하거나 해당 페이지 소스내에서 설정 진행 하셔야 합니다.
Q23. CTlog(투명성 로그)가 무엇인가요?
인증서의 투명성은 SSL인증서를 모니터링 하기 위한 개방형 프레임 워크입니다.도메인 소유자는 자신의 도메인에 대한 인증서 발급을 모니터링 하고 악용되는 인증서를 감지하는 것을 발견할 수 있습니다.CT를 사용하면 모든 인증서가 공개되어 전체적으로 웹 PKI 에코 시스템에 대한 통찰력과 투명성을 높여줍니다.인증서 투명성 프로젝트는 다음 세가지 목표를 달성하는 것을 목적으로 합니다.
1. CA가 해당 도메인의 소유자에게 인증서를 표시하지 않고 도메인에 대한 SSL인증서를 발급을 불가능하게 합니다. (또는 매우 어렵게 만듭니다.)
2. 도메인 소유자 또는 CA가 인증서가 실수로 또는 악의적으로 발급되었는가를 확인할 수 있는 모니터링 시스템을 제공합니다.
3. 실수 또는 악의적으로 발급된 인증서로 사용자를 속이는 것을 방지합니다.인증서의 투명성 프레임워크는 허위 또는 악의적 인증서가 발견될 수 있는 기존 시스템에 비해 빠르고 효율적으로 탐지될 수 있습니다.의심스러운 인증서를 조기에 탐지하면 CA와 도메인 소유자는 모두 신속하게 대응하고 인증서를 철회 할 수 있습니다.
Q24. CAA가 무엇인가요?
CAA는 사이트 소유자가 도메인 이름을 포함한 인증서를 발급할 수 있는 CA (인증 기관)를 지정할 수 있도록 하는 DNS 레코드 유형입니다.CA가 의도하지 않은 인증서 오용의 위험을 줄이기 위해 RFC 6844에 의해 2013년에 표준화 되었으며, 기본적으로 모든 공용 CA는 공용 DNS의 모든 도메인 이름에 대한 인증서를 발급할 수 있습니다다음의 경우, 해당 도메인 또는 하위 도메인에 대한 인증서 발급하는 것이 금지됩니다.
1. CA가 CAA레코드를 가지고 있는 도메인에 대한 인증서를 받은 경우
2. CA가 허가된 발급자로 나열되지 않은 경우CA에서 CAA레코드를 확인 및 검사하지만, CAA를 사용하는 것은 도메인 소유주에게는 선택사항입니다.구현하려는 경우 여러 CA를 지정할 수 있으며, 다음은 CA에 대한 처리 규칙입니다.
◆ CAA 레코드 없음(No CAA record) : CA 발급가능
◆ CAA 레코드를 포함한 CA(CAA record includes CA) : CA 발급가능
◆ CAA레코드이지만 CA는 포함하지 않음(CAA record, but does not include CA) : CA발급 불가능
◎ issue : CA가 인증서를 발급할 수 있도록 허용( Issuewild가 제한하지 않는 한 와일드 카드 인증서 포함)
◎ Issuewild : CA가 와일드카드 인증서를 발급 할 수 있지만, 와일드카드가 아니면 발급이 불가능빠른 검사를 통해, https://crt.sh/를 사용하여 도메인에 발급된 인증서를 쿼리하면, 해당 도메인의 발급 CA 목록을 반환 할 수 있습니다.
Q25. CAA 오류
현재 모든 인증기관은 인증서 발급 전에 CAA 레코드를 확인하기 때문에 CAA 레코드를 설정하지 않은 도메인에 대해서도 오류가 발생할 수 있습니다.
인증기관에서 CAA 오류가 발생하면 인증서 발급이 중단되고, CAA 오류 해결을 요청합니다.
CAA 오류가 발생할 수 있는 경우는 다음과 같습니다.
1. SERVFAIL'SERVFAIL' 오류는 일반적인 오류 중 하나입니다. 이 오류는 대부분 DNSSEC 유효성 검사 실패를 나타냅니다. 'SERVFAIL' 오류가 발생하면 dnsviz.net과 같은 DNSSEC 디버거를 사용해야 합니다.
이 오류는 보통 "CAA 레코드를 확인할 수 없는 경우" 이므로, 해외 방화벽이 있거나, 해외 접속이 차단되어 인증기관에서 CAA 레코드를 확인할 수 없는 경우에도 나타납니다.
2. TimeoutCAA는 시간 초과를 쿼리합니다. 일반적으로 네임 서버가 알 수 없는 쿼리 유형으로 DNS 질의를 삭제하도록 잘못 구성된 방화벽을 가지고 있을 때 발생합니다.
이런 경우, DNS 공급자에게 지원을 문의를 제출하고 방화벽이 구성되어 있는지 확인하셔야 합니다.
Q26. SSL 접속중의 브라우저 하단에 열쇠마크가 안나오는데 어떻게 해야 하나요?
우선, https 통신 여부 확인이 필요 합니다. https 접속을 했음에도 열쇠마크가 안나오는 경우 혼합된 컨텐츠(Mixed Content) 관련 내용으로 소스 수정이 필요 합니다.
브라우저에서는 https로 암호화 통신을 하지만 소스에서는 http 일반 통신을 하여 해당 경고창이 발생 합니다. 확인 방법은 다음과 같습니다.
1. "Mixed content"오류 확인방법 : Chrome 브라우저 접속->개발자도구(F12)-콘솔)-> Console 탭에서 URL 확인
2. Mixed content 관련 내용으로 나오는 http URL을 https로 수정이 필요 합니다.※ 열쇠마크가 표시 안 된다고 하여 암호화 통신이 안 되는 것은 아닙니다.
Q27. SSL 보안 인증서를 설치 할 때 443 Port이외의 다른 Port를 이용할 수 있나요?
SSL 포트는 443 이외 다른 포트를 사용할 수 있습니다.
다만 443 이외 포트는 URL 입력시 포트번호와 함께 입력 해 주셔야 합니다.참고로 포트변경시 방화벽에서의 오픈작업이 필요할 수 있습니다.
EX) 447 포트로 SSL 인증서를 설치 하셨다면, https://(domain):447 형태로 접속이 필요 합니다.
Q28. SSL 인증서를 발급 받았는데 도메인의 IP 주소를 변경해도 괜찮은가요?
SSL 인증서는 도메인 기준으로 발급 되기에 ip가 변경 되어도 영향을 받지 않습니다. 도메인은 동일하나 서버가 이전하여 ip가 변경 됐다면, 새로운 서버에 기존처럼 인증서 설치를 해주시면 됩니다.
Q29. 한 서버에 여러 개의 도메인을 사용하고 있는 경우 SSL 설치가 가능한지요?
한 서버에 여러 개의 도메인을 사용하는 경우 SSL 설치가 가능합니다.다만 한 서버에 여러 개의 도메인 설치하여 각 도메인이 같은 포트 사용을 원하실 경우 멀티 또는 와일드 인증서로 발급하여 적용 하는 것을 권장드립니다.
Q30. KEY파일을 삭제한 경우에는 어떻게 해야 하나요?
KEY파일은 웹 서버내에 보관되어져 있는 고객의 개인키로서, 인증기관은 그에 대한 어떠한 정보도 가지고 있지 않으며 가지고 있어서도 안되는 파일입니다.
인증서는 고객이 웹 서버에서 생성하신 개인키와 쌍이되는 공개키를 인증기관에 보냈을 때, 이를 인증기관에서 심사하여 전자 서명을 해주는 파일입니다.
고객이 개인키를 가지고 있지 않은 경우에는 인증서 설치가 불가능하며, 백업본이 없을 경우 인증서 재발급이 필요합니다.
관련된 자료가 더 필요하신가요?