들짐승 프로그래밍

RSA, SSL, HTTPS에 대한 사전지식이 필요하다.

https://fieldanimal.tistory.com/79?category=908294 

SSL 인증서가 필요한 이유

위 글에서 public key 자체가 잘못된 public key면 내 개인정보를 털릴 수 있다고 했다.

지금 나는 Tistory로부터 public key를 받아서 안심하고 통신을 시작하는데 근본부터 속았다면,,

그럼 public key가 Tistory로부터 받았다는걸 어떻게 증명하냐? 제3기관의 힘을 빌린다. 이들은 믿을만하다는 것이다.

실제로 크롬, 웨일 등 브라우저를 설치하면 자동으로 많은 인증서들이 등록되어있다.

대략적인 과정

클라이언트는 서버로부터 인증서를 받고

인증서에 적혀있는 발급자 서명을 이용해 해당 인증서가 발급자로부터 검증받은 것임을 확인한다.

발급자가 위 리스트에 들어있으면 OK이고 통신을 시작한다.

SSL handshake과정중 certificate 과정이다.

https://aws-hyoh.tistory.com/entry/HTTPS-%ED%86%B5%EC%8B%A0%EA%B3%BC%EC%A0%95-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3SSL-Handshake

<ssl handshake과정>

OpenSSL

OpenSSL이란, TLS 인증서를 만들기 위한 과정을 대신해주는 오픈소스 라이브러리이다.
인증서를 만드려면 private key도 만들고 csr도 만들고 cert도 발급하고 기타 등등을 해야하는데 사용할 알고리즘, 파라미터를 입력해주면 파일로 만들어준다.

아무리 프로토콜이 정해져있다고 해도 우리가 직접 코딩하고 계산해서 만들 수는 없기 때문에 이런 라이브러리를 이용해야한다.

https://aspdotnet.tistory.com/2653

<OpenSSL 설치>

예시로 과정 살펴보기

https://www.lesstif.com/system-admin/openssl-root-ca-ssl-6979614.html

<OpenSSL CLI를 이용한 인증서 발급 과정>

MyCompany : 서버 이름

COMODO : 브라우저에 내장된 신뢰할 수 있는 CA 이름 예시

0. MyCompany의 private key를 만든다.

1. CSR 생성

mycompany 인증서를 위한 CSR를 만든다. CSR은 인증서 발급 요청서 양식이다.
이때 mycompany 도메인, 지역 등의 정보를 기입한다.

2. 인증서 발급

COMODO에게 CSR을 넘겨주고 인증서를 발급받는다.

https://comodosslstore.com/promoads/ssl-certificates.aspx?gclid=CjwKCAjw3cSSBhBGEiwAVII0Z1YlKGMSf60MyriJkTyIIIQn0VYe9TQ0TQHMWy38JbWJ4mnzybWTzxoC5oIQAvD_BwE

<실제 인증기관, https 서버를 정식으로 운용하고싶으면 돈을 내고 인증서를 받을 수 있다.>

인증서 안에는 MyCompany의 도메인, MyCompany의 public key, 발급자(COMODO) 등등의 정보들과 지문이 들어있다. 

지문은 MyCompany의 public key를 COMODO의 private key로 암호화한 서명이다. 실제로는 실제로는 정보들의 해시값을 암호화하지만 이해를 쉽게 하기 위해 public key를 암호화한다고 단순화해서 생각해본다.

https://chickenpaella.tistory.com/40​

3. 클라이언트에게 인증서 전달

요청이 들어온 클라이언트한테 COMODO에서 발급받은 인증서를 던져준다. 이때 클라이언트는 수신한 인증서가 MyCompany가 맞는지 계속 의심을 하고있는 상태이다.

4. 인증서 검증

COMODO는 브라우저가 이미 신뢰하고있는 인증서이다.

COMODO의 Public Key를 이용해 MyCompany 인증서의 지문을 복호화한다.
이때 MyCompany 인증서의 Public Key와 복호화해서 나온 Public Key가 동일하면, MyCompany는 COMODO에게 인증을 받았다는게 확실하고, COMODO는 브라우저가 신뢰하고 있는 기관이므로 MyCompany도 신뢰할 수 있게 된다. 브라우저에는 깔끔한 자물쇠가 뜬다.

5. 인증서 chain

만약에 COMODO가 Root CA가 아닌 중간기관이면 COMODO의 Public Key 또한 믿을 수 없으므로

COMODO 인증서에 적힌 Public Key와

COMODO 인증서의 지문을 발급자(Root CA)의 Public Key로 복호화해서 나온 값을 비교한다.

타고 타고 타고 올라가서 결국 Root CA한테 받은게 맞으면 정말 OK이다.

Root CA란?

https://m.blog.naver.com/alice_k106/221468341565

모든 흐름을 자세하게 설명해놓으신 형님의 글을 보면 된다.

CA Chain을 계속 하다보면 언젠간 꼭대기까지 올라가게되는데 이를 Root CA라고 부른다.

Root CA는 더이상 올라갈 곳이 없기 때문에 지문(서명)을 다른 기관이 아닌 자신의 Private Key로 만든다.
브라우저가 믿을 수 있는 절대 안뚫리는 곳이라고 한다.

사설 인증서 생성

테스트용으로 Root CA를 만들고 그 Root CA로부터 인증서를 발급받아서 서버를 구축해본다.

1. Root CA private key를 만든다.
2. Root CA csr를 만든다(인증서 요청서)
3. Root CA의 인증서를 만든다(crt) : Root가 Root에게 셀프로 발급

4. 서버용 private key 생성

5. csr 생성 후 Root CA로부터 인증서 발급

Root CA를 직접만들어서 Root CA로부터 지문을 받은 인증서는, 브라우저에서 신뢰할수없다고 뜬다.
이유는 브라우저에 등록된 인증서에 당연히 내가 셀프로 만든 인증서가 없기 때문이다.

KeyStore

직접 OpenSSL 명령을 입력해가며 테스트해보니 많은 파일들이 생겼다.

확장자별 의미 : https://www.ihee.com/616

keystore를 이용해서 널부러져있는 파일들을 지갑처럼 한데모아 사용할 수 있다. 

https://dimdim.tistory.com/entry/openssl%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-Tomcat-HTTPS-%EC%84%A4%EC%A0%95-PKCS12-%ED%8F%AC%EB%A7%B7

openssl로 .p12 확장명 keystore를 만들 수 있고

openssl과 비슷한 java keytool로 .jks 확장명 keystore를 만들 수도 있고

둘을 변환하며 쓸 수 있다.

변환 가이드 : https://www.sslcert.co.kr/guides/SSL-Certificate-Convert-Format