마지막으로 직접 인증서를 발급하고 이를 개인용 사이트에 적용하는 방법을 상세히 알아보겠습니다. 

 

이 테스트는 CentOS 7.x , OpenSSL, Nginx에서 실행되었습니다.

 

인증서 발급을 위한 준비

 

인증서를 발급한 기록을 위해 두 가지 파일이 필요합니다. 하나는 발급된 인증서의 정보를 기록하는 것과 serial을 기록하는 파일, 이렇게 두 개의 파일을 준비해야 합니다. 

 

touch /etc/pki/CA/index.txt
echo '00' > /etc/pki/CA/serial

추후 인증서를 발급 후 두 파일을 보면 아래와 같습니다.

V    210109061528Z    00    unknown /C=KR/ST=Seoul/O=COMPANY/OU=DEV1/CN=your_domain/emailAddress=your_email@server.com

index.txt 파일에는 언제 어떤 정보를 포함한 인증서가 발급되었는지가 기록됩니다. 

01

serial 파일에는 00 에서 01로 한 개의 인증서가 발급되었다는 것을 확인할 수 있습니다. 

 

 

이제 CA 개인키를 생성합니다.

openssl genrsa -des3 -out ca.key 1024

그리고 CA의 CSR(Certificate Signing Request)을 생성합니다. csr 파일은 공개키와 사용하는 알고리즘 정보가 포함됩니다.

openssl req -new -key ca.key -out ca.csr

이제 Root CA의 인증서를 생성합니다. 

openssl x509 -req -days 1280 -in ca.csr -signkey ca.key -out ca.crt

이제 개인키에서 패스워드를 삭제하겠습니다. 사실 패스워드가 있는게 당연하겠지만, 웹 서버 가동때마다 계속 패스워드를 물어보게 할 수 없으니 일반적으로 삭제하고 사용합니다. 일반적으로 웹 서버들은 모두 패스워드 삭제를 '강요'합니다.

openssl rsa -in ca.key -out ca_key.pem

이로서 CA로서의 준비를 끝났습니다. 이제 웹서버를 위한 준비를 하겠습니다. 

 

웹 서버 인증서 만들기

웹 서버용 개인키를 생성합니다.

openssl genrsa -des3 -out server.key 1024

웹 서버용 CSR 을 생성합니다.

openssl req -new -key server.key -out server.csr

이제 준비가 되었으니 실제 인증서를 발급해 보겠습니다. 이 글은 개인용 인증서를 생성하고 적용하는 내용을 정리한 글입니다. 공인된 CA에 인증서 생성 요청은 필요하다면 추후 별도로 정리해 보겠습니다. (이미 수많은 글들이 있으니 쉽게 구글링으로 확인하실 수 있습니다.)

 

준비된 CA로 인증서를 제작합니다.

openssl x509 -req -in server.csr -out server.crt -signkey server.key -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

웹 서버에 설정하기 위해 웹 서버용 개인키에서 패스워드를 삭제합니다. (안그러면 웹 서버 실행때마다 물어봅니다.)

openssl rsa -in server.key -out server_key.pem

Diffie-Hellman 키 생성하기 

(* Logjam 취약점이 이전에 발표되었으며, 이로 인해 1024bit는 안전하지 않습니다. 꼭 2048 이상으로 사용하시기 바랍니다. 상세 내용은 구글링으로... ^^a)

openssl dhparam -out dhparam.pem2048

 

이제 위에서 생성한 파일들을 /etc/nginx/ssl 폴더를 만들어 넣어두고 아래와 같이 상위 폴더의 보안 설정에 맞춰줍니다.

restorecon -v -R /etc/nginx

 

웹 서버 (NGINX ) 설정하기 

 

nginx 의 설정을 별도로 수정하지 않았다면 /etc/nginx/default.conf 파일을 수정하면 됩니다.

 

# 기존 http도 https로 리디렉션 되도록 설정.
server {	
	listen      80;
	listen      [::]:80;
	server_name your_domain; # ip 일때는 굳이 쓸 필요가 없다.

# 301 moved permanently 응답과 합께 모든 http 요청을 https로 리디렉션한다.
	location / {
		return 301 https://your_domain:443$request_uri;
	}
}

server {
	listen       443 ssl http2 default_server;
	listen      [::]:443 ssl http2 default_server;
	server_name  your_domain; # ip 일때는 굳이 쓸 필요가 없다.

	ssl_certificate /etc/nginx/ssl/ca.crt;
	ssl_certificate_key /etc/nginx/ssl/ca_key.pem;
	ssl_session_timeout 1d;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;

	ssl_dhparam /etc/nginx/ssl/dhparam.pem;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	# Cipher Suites 에 대해서는 이 링크(https://rsec.kr/?p=455)를 참고하세요. 너무 잘 설명해 두셔서 감동이었습니다. -o-b
	ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
	ssl_ecdh_curve secp384r1;

	ssl_prefer_server_ciphers on;
	ssl_stapling off;	# for self-signed cert
	ssl_stapling_verify off; # for self-signed cert

	location ~ /\.ht {
		deny all;
	}
	.
	.
	.

 만약 443이 아닌 다른 임의의 포트를 사용한다면 semanage에 추가해야 합니다. (selinux를 사용하지 않는 상태라면 통과입니다.)

semanage port -a -t http_port_t -p tcp 4430  # 포트 추가하기
semanage port -l | grep http_port_t # 포트 적용되었는지 확인

firewall-cmd --permanent --zone=public --add-port=4430/tcp # firewall에 4430포트 오픈
firewall-cmd --reload # 변경 사항 적용하기

이제 웹서버를 재실행 해보시기 바랍니다. http로 접속하시면 바로 https로 포워딩 되는지도 잘 확인해보시고요.

 

도움이 되셨으면 합니다.

 

모두 새해 복 많이 받으시고 멋진 2020년 되시기 바랍니다.

 

이만  ~~ !

회사 자체에서 사용되는 웹 사이트에 SSL을 도입할 일이 생겼는데, SSL 도입 자체가 처음이라 도입 과정의 내용을 정리해 보았습니다. Self Signed Certificate이라고 하는 용어도 이번에 첨 알게 되었네요. 

 

필요한 사전 내용부터 도입 과정, 예외상항에 대해서 순서대로 정리 보았으니 참고 되시길 바랍니다. 

(* 처음 해보는 거라 잘못된 정보, 오류가 있을 수 있습니다. ^^;;)

알고 가야 할 것들!

SSL(Secure Socket Layer)이 무엇인지는 너무 많은 글들이 있으니 여기서는 SSL 도입에 필요한 요점만 정리하겠습니다. 사실 TLS(Transport Layer Security)지만 SSL이라고 부르기 때문에 그대로 사용하겠습니다. 

 

HTTP와 HTTPS의 차이

HTTP는 평문(텍스트 그 자체!)으로 데이터를 전송합니다. 즉, 전송되는 데이터를 손쉽게 들여다 볼 수 있습니다. HTTPS는 Secure이 붙은 만큼 전송되는 데이터를 볼 수 있다 한들 암호화가 되어 있어서 무슨 내용인지 바로 알 수 없습니다.

 

그럼 서로 주고 받는 데이터를 암호화 한다면 복호화는 어떻게 할 수 있을까요? 보내는 곳에서 암호화한 방법을 알아야 받는 곳에서 복호화를 할 수 있을텐데?

 

세상에는 수많은 사이트가 존재합니다. 서로 데이터를 주고 받기 전에 암호화를 어떻게 할지 미리 알려줘야 하는데(대칭키 방식) 접속할 때마다 자기가 어떤 방법으로 암호화를 하는지 알려줘야 한다면, 이 방법을 알려주는 순간에 해커들이 이 정보를 훔쳐간다면 무용지물이 되겠죠. 그렇다고 사전에 암호화 하는 방법을 서로 미리 정해놓고 공유한다면 이 또한 안전하지도 않을 뿐더라, 암호화 방식이 바뀔 경우 대책이 없게 됩니다.

 

이를 보완하기 위해 개인키/공개키라는 개념이 나옵니다. 

 

Private Key(개인키)/Public Key(공개키)란?

말 그대로 개인키는 나만 가지고 있고, 공개키는 누구에게든 전달할 수 있는 키입니다. 공개키로 암호화된 데이터는 개인키로만 복호화 할 수 있습니다. 이 역도 성립합니다. 개인키로 암호화한 데이터는 공개키로 복호화 할 수 있습니다.

 

(*Private/Public Key 설명을 돕기 위한 그림으로 실제 위와 같이 데이터를 교환하지는 않습니다.)

그래서 공개키로 암호화된 데이터를 아무리 들여다 봐도 개인키를 모르는 이상 복호화 할 수 없습니다. ( 여기서 굳이 양자컴퓨터를 언급하지는 않겠습니다. ;; )

 

그런데 이 그림처럼 통신하기 위해서는 많은 연산이 필요합니다. 이를 해결하기 위해 핸드쉐이킹 단계 (클라이언트가 서버에 처음 연결하여 통신을 준비하는 단계) 에서 실제 데이터 전송을 위한 대칭키를 결정하는 단계에서만 사용됩니다. 이후부터 세션이 종료될 때까지 결정한 대칭키를 이용해 데이터를 교환하고, 세션이 종료될 때 사용한 대칭키는 파기하게 됩니다. 

 

(* 공개키 기법의 Handshaking 과정)

 

분명히 간단히 정리하려고 했는데, 정리 하다보니 정도 모르는 것들이 또 나와서 정리하고 그림도 그리다보니... 

 

조금 길어졌네요.

 

다음 글에서는 우리가 알고 있는 공인인증서는 무슨 역할을 하고, 왜 인증된 기관에서 받아야 하는지 알아보겠습니다.

 

그 후 마지막에는 Self-signed Certificate 작성과 적용 방법에 대해서 정리하고 마무리 하겠습니다. 

 

Unity5 발표 이후 공개된 여러 AssetBundle 관련 문서를 번역하다가 지금까지 알게된 주요 변경 사항들을 정리해봤습니다. 


처음 만져본 unity 버전이 5.0입니다. 현재 패치툴을 만들면서 보고 있어, 아직 발견하지 못하거나 이해가 낮아 잘못알고 있는 내용들이 발견되더라도 양해 바라면 댓글 달아주시면 수정/추가하겠습니다.

1. 5.0에서는 각 Asset (코드 파일 제외)별로 AssetBundle Name과 variant를 지정할 수 있다. 
   (Asset 미리보기 창의 하단에 설정 UI가 있습니다.)

2. name은 해당 Asset이 속할 AssetBundle의 이름이며, 설정 UI에서 선택하거나 새롭게 생성할 수 있습니다. 
   이 과정은 5.0 이전 버전에서는 수동으로 설정을 해야 했기 때문에 상당히 번거로웠으며, 이 작업을 편리하게 도와줄 수 있는 bundle mnager 같은 에셋이 발매되어 있습니다. (* 최근 5.0 버전에 맞게 개선된 버전이 나왔더군요.)

3. variant는 AssetBundle의 이름에 연결된 옵션이며, unity 공식 데모에서는 앱 실행 중 실시간으로 텍스쳐의 퀄리티를 변경할 수 있는 예로 사용되었습니다. 
 (* http://files.unity3d.com/vincent/assetbundle-demo/users_assetbundle-demo.zip를 참고하세요.)

4. 이전 버전에서는 변경되지 않은 Asset들도 모두 빌드되어 패치를 작성하는데 많은 어려움이 있었다고 합니다. (전 첫 unity 버전이 5.0이라 이전 경험자 분들의 이야기를 들어본 바에 의해서 적습니다.) 5.0 버전에서는 변경된 에셋들만 추려서 빌드됩니다. 

5. AssetBundle 이름을 검색하는 기능이 추가되었습니다. 검색 UI에 "b:"를 입력 후 원하는 에셋번들 이름을 넣으면 해당 이름을 가진 모든 에셋을 볼 수 있습니다.

6. 유니티가 직접 종속 관계를 관리하며, 이는 기존에 사용하던 PushAssetDependencies/PopAssetDependcies API를 사용할 필요가 없습니다. (* 공개된 원문에 있던 내용인데, 이전 버전을 사용해보지 않아 와닫진 않네요. ^^;)

이상입니다. 이 외 typetree, 이전 버전과의 혼용 등에 대한 내용들이 있었는데 추후 내용이 파악되면 추가하겠습니다. ^^a


+ Recent posts