OpenSSL을 활용한 인증서 구현하기(CA, HTTPS)

 

 

 

 

 

인증서를 사용하는 목적 

 

암호화가 없는 패킷은 그 내용이 외부에 모두 드러날 수 있다.

VPN은 암호화 통신의 방식 중 하나이지만, 모든 클라이언트에게 VPN을 연결하는 서비스는 말이 안 된다. 따라서 인증서를 통한 암호화가 서비스 오픈에는 필수적이다.

HTTPS를 위한 CA를 구현해 보자.

 

 

 

구현에 집중하기 위해 모두 같은 네트워크를 사용하여 통신하게 하자.

CA: 100.1.2.6

Server: 100.1.2.4

Window client: 100.1.2.7

 

 

 

 

 

SSL과 TSL를 제공하는 OpenSSL

 

지금까지 ssh 접속을 위해 사용하던 openssl에 대해서 알아보자.

 

OpenSSL은 암호화와 보안 프로토콜을 구현하는 오픈 소스 라이브러리이다. TLS(Transport Layer Security) 프로토콜의 오픈소스 응용 프로그램을 제공하는 종합적인 암호화 라이브러리이다.

OpenSSL은 주로 SSL/TLS 프로토콜을 지원하여 안전한 데이터 통신을 제공한다.

다양한 암호화 기술과 암호 해독, 디지털 서명 등을 지원하여 네트워크 통신 및 보안 응용 프로그램에서 많이 사용된다.

 

 

SSL(Secure Socket Layer)

넷스케이프사에서 1994년 7월에 처음으로 개발한 Secure Socket Layer(SSL) v1.0은 HTTP와 같은 응용계층 프로토콜들에 대한 암호화를 지원하는 트랜스포트 계층에서의 보안 프로토콜이다. 1994년 12월에 개량된 SSL v2.0이 연속 발표되었으며, 1년 뒤인 1995년 11월에 최종 버전인 3.0 버전이 발표되었다.

 

 

TLS(Transport Layer Security)

Transport Layer Security(TLS)는 SSL 3.0을 기초로 IETF에서 1999년에 RFC 2246으로 표준으로 만든 것으로서, SSL 3.0과 유사하지만 호환은 되지 않는다.

이러한 TLS/SSL은 다음과 같은 기능을 제공한다.

 

• 메시지의 압축
• 변조 방지된 종단 간 연결로 제공 : HMAC에 의한 메시지 무결성 제공
  • HMAC-MD5
  • HMAC-SHA-1
• 인증서를 이용한 서버 및 클라이언트 인증
• 공유 비밀키 설정
  • RSA 공개키 교환 방식
  • Diffie-Helman 키 교환 방식
• 공유비밀키에 의해 암호화된 종단 간 연결로 제공 : 스트림 또는 블록 암호화 방식 사용
  • 스트림 암호화 : 40비트와 128비트의 RC4
  • 블록 암호화 : IDEA, 40비트와 56비트의 DES, 168비트의 3DES

이러한 SSL/TLS의 위에서 동작하는 것이 HTTPS와 FTPS이다.

 

 

 

여기서 공개키가 인증되었는지 여부를 파악하는 데 사용되는 것이 우리가 오늘 만들어볼 인증서이다.

 

 

 

 

 

 

FTPS vs SFTP vs SCP

그렇다면 FTPS와 SFPT 그리고 SCP의 차이는 무엇일까.

 

 

FTPS (FTP Secure / FTP SSL)

FTP over SSL

HTTPS처럼 TLS/SSL 레이어 위에서 작동하는 안전한 프로토콜이다.

FTPS는 일반적으로 쓰이는 파일 전송 프로토콜의 확장으로, 기존의 FTP에 전송 계층 보안과 보안 소켓 계층 암호화 프로토콜에 대한 지원이 추가된다.

 

 

SFTP (SSH FTP / Secure FTP)

SSH를 사용해서 파일을 암호화해서 전송하는 프로토콜이다. 따라서 SSH와 동일한 22번 포트에서 동작하게 된다.

 

 

SCP (Secure Copy Protocol)

로컬 시스템과 원격 시스템 간에 파일 및 디렉터리를 안전하게 복사하는 데 사용되는 명령줄 프로그램이다. SCP도 SSH (Secure Shell) 프로토콜 위에서 작동하며, 파일 전송 시에 데이터가 암호화되어 보안이 유지된다. 연결이 빠르지만, Unix 계열에서만 사용되고 4GB 이상의 파일은 전송이 불가능하다.

 

 

 

SSH vs SSL/TLS

SSH도 공개키/개인키를 사용하기 때문에 헷갈릴 수 있다. (사실 내가 헷갈림 :)

암호화 방식과 대칭키 전달 방식은 비슷하다.

하지만, SSH는 어디까지나 다른 디바이스에 로그인하여 원격으로 명령어 실행을 위한 프로토콜이다.

반면에 SSL과 TLS의 위에는 다양한 프로토콜을 올려서 동작시킬 수 있으므로 훨씬 범용적으로 사용된다.

 

 

 

 

 

 

 

CA 서버에서 인증서 만들어 보기

 

sudo apt-get update

sudo apt install openssl    #open ssl 설치

 

 

 

 

- genrsa : rsa 개인키 생성

- des3 : 3DES (Triple Data Encryption Standard) 알고리즘을 사용하여 개인 키를 암호화

- out { 파일명 } : 생성할 개인키 파일명으로 생성

- 2048 : RSA 의 비트 수를 2048bit로

 

생성되는 키

 

여기서 생성되는 key 개인키만이다.

RSA는 소수로 이루어져 있으므로 소수인 개인키로 다른 소수인 공개키를 만들 수 있다.

 

penssl rsa -in rsa_private.pem -pubout -out rsa_pub.pem

 

 

 

 

 

인증 요청서 만들기

 

인증 요청서는 CA에게 자신의 인증서 발급을 요청하는 파일이다.

요청을 위해서 개인키를 사용해 만든다.

 

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

 

 

 

명령어 실행 시, 몇 가지 input을 받는데 실제 서비스에서 Common Name부분을 제대로 작성해주지 않으면 인증서가 동작하지 않는다.

 

- q : 인증서 요청을 생성하는 명령어

- new : 새로운 인증서 요청

- days { 일수 } : 인증서 유효 기간 설정

- key : RSA 개인키를 사용하여 인증서 요청 (만들어 둔 server.key로)

- out { 파일명 } : 생성할 인증 요청 파일명

 

 

 

Root CA는 스스로에게 인증서를 서명해서 발급한다.

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

 

 

 

자신의 server.key와  server.csr를 이용하여 인증서를 발급한다.

in { 파일명 } : 서명할 인증서 요청 (CSR) 파일 지정

 

 

 

 

 

 

CA에게 인증 요청 보내기

 

sudo apt install openssl

 

openssl genrsa -aes256 -out web.key 2048

 

- 3DES (Triple Data Encryption Standard)는 브루트 포스 공격에 취약점이 발견되어 해독에만 사용하고, 더 이상 암호화에는 사용하지 않는다. 다라서 aes256을 사용해 주자.

 

 

 

 

#인증 요청서 생성

openssl req -new -days 365 -key web.key -out web.csr

 

 

 

생성된 인증 요청서는 CA로부터 인증을 받아야 한다.

 

요청서인 web.csr 전송을 위해 파일 경로를 확인.

일반적으로 명령어를 진행한 경로에서 생성된다.

 

 

 

 

 

CA에게 전송한다.

sudo scp web.csr jin@100.1.2.6:web.csr

 

 

 

 

전송된 것이 확인됨.

 

 

 

CA가 인증서를 자신 개인 key를 사용해서 인증한다.

따라서 해당 인증을 CA의 공개키로 복호화하면, CA가 인증했음을 확인할 수 있다.

 

 

 

openssl x509 -req -days 365 -extensions v3_user -in web.csr -CA server.crt -CAcreateserial -CAkey server.key -out web.crt

 

• extensions v3_user : 인증서 확장을 지정, v3_user 는 v3 확장을 사용하는 사용자 정의 구성 파일을 나타냄
• in web.csr : 서명할 인증서 요청 (CSR) 파일인 web.csr 을 지정
• CA server.crt : CA 서명에 사용할 CA 인증서인 server.crt 파일을 지정
• CAcreateserial : 새로운 일련번호 파일을 생성합니다. CAcreateserial 옵션이 없으면 명령어 실행 시 에러가 발생할 수 있다.
• CAkey server.key : CA 서명에 사용할 CA 개인 키인 server.key 파일을 지정
• out web.crt : 생성된 서명된 인증서를 web.crt 파일에 저장

 

 

 

 

 

 

 

서명 전의 인증서는 Certificate requset가 앞뒤로 붙어 있지만

 

 

 

 

서명된 인증서는 Certificate가 붙어있다.

 

 

 

 

 

 

 

FTP 서버 SSL 설정

 

apt-get install vsftpd -y

 

 

sudo nano /etc/vsftpd.conf          #설정 파일에 아래 내용 추가

 

write_enable=YES

user_sub_token=$USER

local_root=/var/www/ftp             #FTP 파일 전송 경로

userlist_enable=YES

userlist_file=/etc/vsftpd.user_list    #화이트 리스트 유저

userlist_deny=NO

 

 

 

 

 

sudo vim /etc/vsftpd.user_list        #root를 추가

 

 

sudo vim /etc/ftpusers에서 블랙리스트된 root를 주석처리

 

 

 

재 시작하면, window 10 VM의 파일질라에서 root로그인으로 접근이 된다.

sudo systemctl restart vsftpd

 

보안이 되지 않는 서버는 메시지가 확인됨.

 

 

 

 

 

 

 

 

FTP 서버에서 인증서 발급

 

 

새로운 개인키 발급

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

 

 

 

 

자신의 서버 Ip를 명시해서 새로 생성해야 정상적으로 사용이 된다.

 

 

 

CA 측에 전송

 

sudo scp ftp.csr jin@100.1.2.6:ftp.csr

 

 

 

 

CA 측에서도 CA 인증서를 새로 생성

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

 

 

 

fpt의 인증서에 서명

openssl x509 -req -extensions v3_user -in fpt.csr -CA ca.crt -CAcreateserial -CAkey ca.key -out ftp.crt

 

 

 

 

서명한 ftp 인증서를 전달

sudo scp ftp.crt jin@100.1.2.4:ftp.crt

 

 

 

 

#FTP 서버의 SSL 활성화

nano /etc/vsftpd.conf     

 

rsa_cert_file=/ssl/server.crt    #인증서와 키의 경로 세팅

rsa_private_key_file=/ssl/server.key

ssl_enable=YES

force_local_data_ssl=YES

force_local_logins_ssl=YES

ssl_tlsv1=YES

ssl_ciphers=HIGH

 

 

 

 

service vsftpd restart

 

 

 

 

 

윈도우에서 접속 시도 시, 인증서 창이 확인된다.

 

 

 

 

 

 

 

 

NGINX에서 HTTPS 사용하기

 

동일한 방식으로 web server의 인증요청서를 ip를 넣어서 만들고, CA에게 인증서를 받으면 된다.

또는 FTP를 위해 만든 인증서를 그대로 사용할 수 있다. (실제 서비스라면 당연히 x)

 

 

 

Nginx에서 HTTPS를 사용하도록 세팅을 바꾸어 주자.

nano /etc/nginx/sites-available/default

 

server {

    listen 443 ssl default_server;

    listen [::]:443 ssl default_server;

    ssl_certificate /home/jin/web.csr;

    ssl_certificate_key /home/jin/web.key;

    ....

}         

 

 

 

 

 

이 상태로 Nginx를 재시작하면 오류가 발생한다.

 

Log를 확인해 보면 사용하는 Key의 비밀번호를 입력하지 않아 오류발생 중이다.

 

 

 

 

 

비밀번호를 가진 ssl.pss 파일을 만들어 주어자.

 

 

 

ssl_password_file    /home/jin/ssl.pass;

Password path 추가로 자동 입력하게 만든다.

 

 

이제 정상적으로 재시작이 된다.

 

 

 

 

윈도우에서 접속해 보자.

 

 

 

 

 

 

 

 

인증된 CA가 아니기 때문에 안전하지 않다는 메시지가 나오고 있지만, https는 정상 동작 중이다.

 

 

 

 

 

이 경고창을 없애려면, CA의 인증서를 브라우저를 띄우고 있는 Window와 Nginx server에 적용시켜 주면 된다.

 

window에서 하는 법은 인터넷에도 많다.

 

ubuntu에서 CA 적용 예제

https://linuxopsys.com/topics/create-certificate-authority-on-ubuntu-linux

How to Create a Certificate Authority (CA) on Ubuntu Linux