[이현철]님이 남기신 글:

>제의 개념 부족인지 모르지만.
>상용화용  ca와 서버에서 만든ca(테스트용ca)를
 사용할경우
>다른점은 단지 웹브라우저 접속시 서버에서 만든 ca를 사용해서 서명한 사이트 경우에는
경고창이 뜬다는것으로 알고있습니다.
>(신뢰성이 없는 사이트라는 형태의 메세지)
>
>상용화ca라는것을 사용하는 이유는 신뢰성을 믿고 사이트를 이용해도 된다는 판단이라고
생각합니다.
>
>그 이외 기능은 같다고 생각합니다.(암호화 처리)


예. 그렇습니다.

사설인증서를 사용하더라도 테스트는 동일하게 하실 수 있으며,
내부용으로 사용하는 것이나 단지 암호화를 위한거라면 사설인증서를 사용해도 됩니다.


>----------------   ------------------ --------------------
>현재 1대서버에 2개의 도메인이 존재하고 두개의 도메인 전부(http)웹서비스 그리고

>하나의 도메인에 관해서만(https) 이용하고있습니다.(상용화키를
 이용하지 않음-테스트용ca를 가지고 https형태로 이용중)
>
>httpd.conf에는 
>---------------------------------------------------
><VirtualHost xxx.xxx.xxx.xxx:80>
>    ServerAdmin xxxxxxxxx
>    DocumentRoot /home/xxxxxxx
>    ServerName zec.gigaprize.co.jp
>    ErrorLog logs/error.log
>    CustomLog logs/access.log common
></VirtualHost>
><VirtualHost xxx.xxx.xxx.xxx:80>
>    ServerAdmin xxxxxxxxx
>    DocumentRoot /home/xxxxxxx
>    ServerName gourmet-star.gigaprize.co.jp
>    ErrorLog logs/error_1.log
>    CustomLog logs/access_1.log common
></VirtualHost>
>---------------------------------------------
>
>
>http://zec.gigaprize.co.jp/index.html (현재 index.html와
존재하지 않치만 도메인까지 접속은 가능함)
>http://gourmet-star.gigaprize.co.jp/index.html (현재 test용
index.html)이 존재함
>
>----------------------------------
>ssl.conf에는 
>--------------------------
><VirtualHost _default_:443>
>#   General setup for the virtual host
>DocumentRoot /home/xxxxxxx
>ServerName gourmet-star.gigaprize.co.jp:443
>ErrorLog logs/ssl-error_log
>TransferLog logs/ssl-access_log
>-----------------------------------------------
>gourmet-star.gigaprize.co.jp 만 https(ssl)형태로 설정이 되어 있음.
>
>
>----
>실제 접속을 해보시면 알시겠지만
>https://gourmet-star.gigaprize.co.jp/index.html 
>제대로 접속이 되고 있습니다.
>
>그런데 
>https://zec.gigaprize.co.jp/index.html 
>로 접속해보면 이 도메인도 https로 접속되어 버립니다.(index.html은
 실제존재하지 않는데,내용을 보면 gourmet-gigaprize.co.jp 형태로
접속해버립니다.(웹브라우저
 URL은 zec.gigaprize.co.jp 인데 index.html은
>gourmet-star.gigaprize.co.jp 내용이 보이고 있습니다)
>
>
>
>-------질문 1입니다..-----------------

>위의 결과를 보면 1대의 서버에 443의 포트로 요청이(https가 설치되어있지않은 도메인도
) ssl.conf에 설정된 도메인으로 결과를 보여주고 있는데 이것이 정상인지요?
>>>> 개인적으로 https 설정되지 않은 도메인 경우에는 80은 보여주지만
>443관해서는 에러가 나는 것이 정상이라고 생각하는데 .....
>아니면 제 설정이 잘못되었습니까?
>------------------------------------

정상적인 현상입니다.
이유는 아래 질문에서 답변.


>--------질문2입니다-------------------

>그리고 위의 두개 도메인을 전부 https형태로 시험해봤지만.
>(ssl.conf에 버츄얼로 두개의 도메일 등록-물론 ca와 각각 도메인별로 만들었음-테스트용
ca를 사용)
>
>두개의 도메인을 등록 후 아파치설정 syntax테스트
>#sh apache2/bin/apachectl configtest
>Syntax OK
>그리고 restart 한후 error.log를 보면 기존의 443포트가 이용하고 있기때문에
apachessl를 기동할수없다고 나옵니다.
>결국 한대의 서버에 443포트는 하나의 도메인만 움직일수 있다는 결론인데요.(80포트는
 몇개의 도메인을  띄울수있는데 말이죠)
>
>결국 한대의 서버에 하나의 도메인만 https형태로 작동하는지요.
>--------------------------------------------------------------
>(상용화 ca사이트에 보면 700달러 정도주면 서브도메인(aaa.domail.com
 ,
>bbb.domail.com) 까지 전부 대응하는 ca도 팔고 있는데요..
>---------------------------------------------------------------
>


우선 님이 처음 질문올릴 때 말씀하신,
여러 도메인을 SSL로 서비스를 한다면

1) 한 서버에 여러 IP를 할당하고, 웹서버는 각각의 IP에 바인딩해서 올리셔야 합니다.
   또는 https 포트를 443외에 각 도메인별로 다르게 하여 바인딩하거나.

2) 완전히 다른 서버에 한대당 하나의 도메인을 사용해야합니다.

80포트처럼 https를 도메인기반 virtual 설정으로는 안됩니다.

이유는 프로토콜의 계층만 이해하면 간단합니다.
HTTPS로 표시되는 SSL프로토콜층은 HTTP보다 하위에 있습니다.
그런데 웹서버의 virtual host설정에 의한 도메인정보는 HTTP의 헤더에 붙어있습니다.
즉, SSL프로토콜은 HTTP보다 하위이니 HTTP의 헤더를 이해를 못하는 것이겠죠.
따라서 도메인기반 virtual host설정과는 다르게 어떤 도메인으로 들어오든 첫 설정에
따라 결정이 되는겁니다.

layer는 http://coffeenix.net/doc/network/ssl_fig3.gif 에서 볼 수 있고,
이유는 http://www.modssl.org/docs/2.8/ssl_faq.html 에서 볼 수
있습니다.

Why can't I use SSL with name-based/non-IP-based virtual hosts?    [L]

The reason is very technical. Actually it's some sort of a chicken and egg problem:
The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP.
When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the
SSL protocol parameters with the client. For this mod_ssl has to consult the
configuration of the virtual server (for instance it has to look for the cipher
suite, the server certificate, etc.). But in order to dispatch to the correct
virtual server Apache has to know the Host HTTP header field. For this the HTTP
request header has to be read. This cannot be done before the SSL handshake is
finished. But the information is already needed at the SSL handshake phase. Bingo! 

그리고, VeriSign의 경우 global한 것이냐에 따라 가격과 암호화 수준이 달라집니다.