HTTPS 연결해보기

 

데이터 평문전송 항목의 대응 방안 중 하나로 쓰긴 했지만 직접 적용해보면 어떤 문제가 있을지 궁금해서 진행해봄

 

▶ 현재 환경 세팅

1. Virtual Box 7.1.4 + 우분투 리눅스 20.04

2. 우분투 APM (Apache2 + PHP + MySQL)

3. 기본 웹 루트 경로 /var/www/html

4. 호스팅 안함 (로컬 서버)

 

 

 

▶ 목차

1. 이전에 찾았던 HTTPS 적용 순서
2. 내 서버에 HTTPS 적용해보기 (자체 서명)
3. 노트북에 루트 인증서 설정해서 브라우저가 신뢰하게 하기 (로컬 CA) (실패)
4. 노트북에 루트 인증서 설정해서 브라우저가 신뢰하게 하기 찐막 (로컬 CA) (성공)
5. 스마트폰에 루트 인증서 설치해보기
6. 정리

 

 

 

< 내가 찾았던 HTTPS 설정 순서 >

1) SSL 모듈 활성화

sudo a2enmod ssl

 

2) certbot 설치

sudo apt-get update 
sudo apt-get install certbot python3-certbot-apache

 

3) Let's Encrypt 인증서 발급

sudo certbot --apache

 

4) /etc/apache2/sites-available/000-default.conf 등 아파치 설정 파일 수정

<VirtualHost *:80> 
 ServerName example.com 
 Redirect permanent / https://example.com/ 
</VirtualHost> 

<VirtualHost *:443> 
 ServerName example.com 
 SSLEngine on 
 SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem 
 SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem 
 SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 
 SSLCipherSuite HIGH:!aNULL:!MD5 
 SSLHonorCipherOrder on 
 DocumentRoot /var/www/html 

 <Directory /var/www/html> 
   AllowOverride All 
 </Directory> 
</VirtualHost>

 

5) Apache 설정 파일 활성화 및 재시작

sudo a2ensite example.com.conf 
sudo systemctl restart apache2

 

***보안이 취약한 SSLv2, SSLv3, TLSv1.0, TLSv1.1 버전은 비활성화***

 

 

 

* 내 서버는 로컬 서버라 이거 적용 못함 *

 

• 못하는 이유_____

1) HTTPS 연결을 위해서는 브라우저에 인증서를 보내야함. 이때 인증서의 서명이 자체 인증이냐, 공인 인증이냐에 따라 HTTPS 연결 방법이 달라짐

2) 위 방법은 공인된 인증서 발급 기관(CA)에서 ssl인증서를 받는 방식

3) 공인 인증 기관(let's encrypt, degicert 등)에서 ssl인증서를 받으려면 내 서버가 공인 도메인이나 ip를 사용해야 함.

4) 내 서버는... 아무도 모름... 내 옆집 사는 분이 나한테 ping 보내도 응답 못함...(공인 서버가 아니라 로컬 서버임)

5) 로컬 서버는 공인 인증 기관에서 인증 안해줌

 

• 다른 방법_____

1) 자체 서명 인증서

2) 로컬 CA

 

• 위 방법의 차이_____

1) 자체 서명 인증서 방식

인증서 만들 때 서명까지 한번에 해서 비교적 과정이 단순하지만 한 번에 한 서버에만 서명하게 할 수 있음

 

2) 로컬 CA 방식

개인키와 인증서를 따로 만들어서 다른 서버의 인증서도 이 CA가 서명하게 할 수 있음.

 

• 실습 방향_____

목표: https 패킷을 호스트머신(노트북)의 와이어샤크로 잡기

 

내 경우 우분투 서버만 있기도 하고 루트 인증서를 내 스마트폰에만 설치할 거라 사실 뭘 하든 상관 없기 때문에 일단 로컬 CA 없이 자체 서명하는 방식으로 진행해볼 생각

 

 

 

 

그밖의 잠재적 문제점

**현재 와이파이 환경에서 실습하고 있어서 ip 변동 문제로 가상머신이나 노트북을 껐다 키면 https가 끊길 수 있음 

-> 매번 인증서 설치하지 않으려면 와이파이 설정 변경으로 ip 고정하거나 로컬 도메인 설정 필요

-> 로컬 도메인 설정해서 노트북 /hosts 파일 수정.(이후 아이피 변하면 서버 설정 파일이랑 노트북 /hosts 파일만 수정하면 됨) 노트북에서만 도메인으로 접근하고 패킷 캡처하려고 스마트폰으로 접근할 때는 아이피를 사용하기로 함

 

 

 

< 내 서버에 적용해보기 >

㉮ 개인키 + 인증서 생성

openssl req -newkey rsa:2048 \
            -x509 \
            -sha256 \
            -days 365 \
            -nodes \
            -out server.crt \
            -keyout server.key

(https://jjeongil.tistory.com/1555)

• openssl req : 인증서 서명 요청 (CSR) 생성
• -newkey rsa:2048 : 새 개인키 생성 (rsa방식으로 2048비트 길이)
• -x509 : req랑 같이 쓰면 요청(CSR) 말고 바로 자체 서명 인증서 뽑아줌
• -sha256 : 인증서의 무결성을 검증할 때 사용할 해시 알고리즘(***)
• -days 365 : 인증서 유효기간 365일
• -nodes : No DES라는 뜻. 개인키를 평문으로 저장 + 쓸 때 비번 입력 생략 (openssl 3.0부터는 -noenc로 사용됨)
• -out server.crt : 생성할 인증서 파일 이름
• -keyout server.key : 생성할 비밀키 파일 이름

 

***-sha256 부분 추가 설명

해시 -> 무결성 검증

암호화 -> 기밀성 목적

 

1) 서버가 인증서 만들 때

인증서 내용 + 인증서 내용을 해시 알고리즘에 넣어서 해시값 만들고 그걸 개인키로 암호화한 디지털 서명 값

이 두 개를 포함해서 인증서를 만듦

 

2) 클라이언트가 인증서 무결성 검증할 때

저 인증서 받아서 인증서 내용을 해시화하여 해시값 만듦

디지털 서명 데이터를 공개키로 복화화하여 위에서 얻은 해시값과 비교

같으면 무결성 검증 완료

 

**이때 개인키와 공개키는 짝꿍이라 공개키로 서명을 복호화할 수 있다는 건 그걸 암호화한 개인키가 ㄹㅇ 서버의 것이 맞다는 뜻으로 해석할 수 있음. 그래서 HTTPS는 패킷 암호화, 무결성 뿐만 아니라 신원 인증의 기능도 함.(신원 인증을 위해 인증서 내용에 포함된 도메인(Subject)이나 CA의 신뢰성 등도 확인함)

 

추가로 입력해야하는 것들 맨 마지막에서 두번째 Common Name*(도메인 이름)은 중요함

인증서에 표시된 도메인 이름이랑 URL로 입력한 도메인을 브라우저가 비교해서 다르면 경고 표시함 (근데 나는 로컬 도메인 설정을 안해서 도메인 이름을 통한 URL 접속이 아직 안됨)

개인키와 인증서가 생성된 모습

 

 

 

㉯ Apache 설정 파일 수정

• /etc/apache2/sites-available/default-ssl.conf

SSLEngine on
SSLCertificateFile      /etc/ssl/server.crt
SSLCertificateKeyFile   /etc/ssl/server.key

위 내용 추가

이때 파일 경로는 apache가 접근 가능한 곳이어야 함.

(처음엔 루트 홈 디렉터리에 만들어서 그렇게 설정했다가 아래 단계에서 오류났음. 이후 위에 쓴 디렉터리 mkdir로 만들고 인증서랑 개인키 파일 복사(cp)한 다음 설정 파일 위와 같이 수정해서 사용)

 

• ssl 모듈 및 사이트 활성화

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo systemctl reload apache2

 

 

 

㉰ 접속 테스트

인증서 만들 때 설정한 도메인으로 접속 시도한 모습 도메인 설정을 추가로 해야 접속할 수 있을 것 같음

 

아이피로 접근한 모습 계속 진행하기 위해 하단의 "고급" 버튼 클릭함

 

인증서 날로 먹어서(인증 서명을 검증된 곳이 아니라 자체적으로 함 + 인증서에 표시된 도메인이랑 URL 다름 등) 브라우저가 손절 치는 모습 아랑곳 않고 하단의 내 서버로 이동하기를 클릭

 

접속됨

 

• HTTP 연결 시 ↓

스마트폰에서 http로 접속하고 로그인했을 때 패킷이 평문으로 노출되고 있음

 

• HTTPS 연결 시 ↓

스마트폰에서 https로 접속하고 로그인했을 때 안녕 안녕 악수하고 암호화된 패킷이 전송되고 있음

프로토콜 설정은 따로 안했는데 TLS1.3이 기본인가?

 

암호화는 잘 작동하지만 브라우저가 신뢰하지 않음

브라우저가 신뢰하게 하려면 루트CA를 통해 인증서 만들어야 함

 

 

 

 

< 노트북에 루트 인증서 설정해서 브라우저가 신뢰하게 하기 >

㉮ 루트 CA의 개인키 생성

openssl genrsa -out rootCA.key 4096

1) openssl genrsa : RSA 개인키 생성

2) -out rootCA.key : 해당 파일로 키 뽑아냄

3) 4096 : 키 길이. 512비트 이하는 허용 노.(기본은 2048비트) 이 옵션은 옵션들 중 가장 마지막에 적어야 하는가 봄.

 

 

㉯ 루트 인증서 발급

openssl req -x509 -new -nodes \
  -key rootCA.key \
  -sha256 -days 1024 \
  -out rootCA.crt

 

1) openssl req : 인증서 서명 요청 (CSR) 생성

2) -x509 : req랑 같이 쓰면 요청(CSR) 말고 바로 자체 서명 인증서 뽑아줌

3) -new : 새 인증서 생성 요청 (인데 -x509가 있어서 요청 말고 바로 서명)

4) -nodes : No DES라는 뜻. 개인키를 평문으로 저장 + 쓸 때 비번 입력 생략 (openssl 3.0부터는 -noenc로 사용됨)

5) -key rootCA.key : 루트 인증서에 서명할 때 (서버 인증서 만들면서) 이미 생성한 CA 개인키를 사용

6) -sha256 : 인증서의 무결성을 검증할 때 사용할 해시 알고리즘

7) -days 1024 : 인증서 유효 기간

8) -out rootCA.crt : 생성할 인증서 파일 이름 (이 인증서는 클라이언트 측에 저장됨)

 

명령어 실행한 뒤 서버 인증서 만들 때와 같이 입력할 거 입력하고 엔터 그럼 현재 디렉토리에 루트 인증서와 루트CA의 개인키가 생성된 것을 볼 수 있음

 

 

server.crt (서버 인증서)  VS rootCA.crt (루트 인증서)

1) server.crt

저장되는 곳 : 서버

역할 : 브라우저가 서버에 파일 요청할 때(url 접속) 저 이런 사람입니다 하는 거 

 

2) rootCA.crt

저장되는 곳: 클라이언트

역할: 저 사람(server.crt) 믿어도 되나 결정할 기준

 

㉰ 서버 용 개인키 새로 발급

openssl genrsa -out server.key 2048

(근데 이건 굳이 새로 만들 필요는 없긴 함)

 

 

㉱ 서명 요청(CSR) 생성

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

 

(마지막 password랑 company name은 그냥 엔터 쳐서 넘어가도 됨)

(password는 인증서 요청을 검증하거나 취소할 때 사용한다고 하는데 보통 잘 안 쓴다고 함)

 

 

 

㉲ 루트 CA(인증 기관)로 서버의 서명 요청(CSR)을 서명해서 인증서 생성

openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key \
  -CAcreateserial -out server.crt -days 365 -sha256

• openssl x509 : X.509 인증서 쓸거임
• -req : CSR 있는 거 그거 기반으로 서명받을 거임
• -in server.csr : 이 CSR 기반으로 해주셈
• -CA rootCA.crt : 공개키가 포함된 로컬 CA의 인증서. 이 CA 이름으로 서명해주셈
• -CAkey rootCA.key : 위 CA의 개인키. 실제 서명에 쓰임.
• -CAcreateserial : 서명할 때 인증서 시리얼 번호 필요하니까 자동으로 rootCA.srl 파일 만들어서 고유 시리얼 번호 부여하셈
• -out server.crt : 만들 서버 인증서 파일. CA가 여기 서명한 결과물
• -days 365 : 인증서 유효 기간 (1년)
• -sha256 : 인증서 해시화할 알고리즘

 

 

 

㉳ 루트 인증서 호스트머신에 전송 후 적용

우선 rootCA.crt 파일을 접근 가능한 /etc/ssl/rootCA.crt로 복사하고

노트북에서 SFTP로 파일 갖고 옴

 

호스트 머신으로 가지고 온 루트 인증서

이걸 노트북의 인증서 관리에서 신뢰할 수 있는 루트 인증 기관으로 설정해줌

 

 

1) 작업 표시줄 쪽 검색창에 "인증서"를 입력하고 "컴퓨터 인증서 관리"에 접속함

 

2) 여기서 신뢰할 수 있는 루트 인증 기관 항목의 인증서를 우클릭한 뒤 가져오기를 클릭함

 

3) 로컬 컴퓨터 그거 선택하는 거 다음으로 넘어가서 가져올 파일에서 루트 인증서 파일을 선택한 뒤 다음 누름

 

* 아래 창이 뜰 수 있음 걍 "예" 누름

 

 

 

4) 루트 인증 기관의 인증서 항목에 들어가있는 걸 확인함

 

 

 

 

㉴ 서버 접속 후 브라우저 반응 확인

전혀 신뢰하고 있지 않는 것을 볼 수 있음 하지만 당황하지 말고 원인을 찾아봄

페이지 하단의 고급 버튼을 클릭함

오류 코드에 인증서에 나쁜 도메인이 있다고 언급하고 있음 아래 인증서 보기를 눌러봄

요청된 도메인 이름이 서버 인증서와 일치하지 않고 있어서 문제라고 함

 

내 인증서에서 표기한 서버 도메인은 test-paint.local이었음

그런데 내가 접근한 url은 서버의 아이피를 통하고 있기 때문에 문제가 되고 있는 거임

 

별로 친하지 않은 사람이 "제가 김방구로 오후 2시에 5만원 입금해줄게요~"해서 "넹~"했는데

정확히 오후 2시에 5만원이 곽두팔 이름으로 들어오면 방구씨한테 확인 전화를 해야하지 않겠음?

 

지금 노트북에 있는 루트 인증서는 test-paint.local 도메인으로 설정됨

브라우저에 저 도메인이 아니라 아이피로 접속함

브라우저가 내 서버에 ssl인증서 요청

내 서버가 서버 인증서를 줌

서버 인증서에 있는 CN(test-paint.local)과 url에 있는 주소를 비교했을때 test-paint.local != 192.168.x.x니까

이자식 못 믿을 자식인데 진짜 여기 들어갈 거임? 하고 있음

 

그리고 현재 브라우저가 인식한 인증서의 발급자 이름이 test-paint.local이 아니라 ubuntu임.

이건 지금 내가 설정한 인증서가 아니라 ubuntu 기본 인증서를 사용하고 있다는 뜻이고

ssl 설정 파일이 뭔가 잘못됐을 수도 있다는 뜻

 

• 지금 해야하는 거

1) SAN(Subject Alternative Name) 파일 만들어서 브라우저가 로컬 도메인 인식하게 만들기

2) 서버 설정 파일 확인하고 인증서나 개인키 저장 경로 등이 잘못 설정됐다면 수정하기

 

 

㉵ SAN을 포함한 openssl 설정 파일 만들기

• openssl-san.cnf

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
x509_extensions    = v3_req
prompt             = no

[ req_distinguished_name ]
CN = test-paint.local

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = test-paint.local
IP.1 = 가상머신 아이피

헷갈릴 일 없게 ssl 설정 파일에서 명시한 서버 인증서&개인키 저장 경로에 만듦

 

• /etc/apache2/sites-available/default-ssl.conf

<VirtualHost *:443>
    ServerName test-paint.local
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/server.crt
    SSLCertificateKeyFile /etc/ssl/server.key
</VirtualHost>

 

• 설정파일 문법 확인 + 서버 설정 로드

sudo apache2ctl configtest
sudo systemctl reload apache2

 

해도 안됨 왜냐면 내 서버는 로컬이라 도메인을 만들어도 다른 기기에서 그 도메인을 찾을 수 없기 때문임.. 아이피와 도메인을 매핑해야 찾게 만들 수 있음

 

 

• /etc/hosts로 ip와 도메인 매핑

내 호스트머신(노트북)의 운영체제: Windows

1) 시작 버튼의 메모장을 우클릭하고 "관리자 모드로 열기" 클릭

2) 파일 - 열기 누르고 파일 형식: 모든 파일 상태에서 아래 경로 입력 후 열기

C:\Windows\System32\drivers\etc\

3) 파일 맨 아래에 내 서버 아이피, 사용할 도메인 이름 입력하고 저장, 닫기

192.168.x.x     test-paint.local

 

4) 브라우저에서 접속

크롬으로 접속한 모습

엣지에서 접속한 모습

파이어폭스로 접속한 모습

파이어폭스는 잘 되는 중. 인증서 발급자도 test-paint.local로 인식 잘 되고 있음 근데 크롬이랑 엣지는 문제가 생긴 걸 보니까 파이어폭스는 버프 스위트의 인증서가 오류를 막아주는 것 같기도 함

 

 

• 크롬과 엣지에서 띄운 오류 코드

net::ERR_CERT_AUTHORITY_INVALID

 

 

오쉣 찾아보니 루트 인증서의 CN을 서버 도메인 이름으로 설정해서 브라우저가 이걸 루트 인증서가 아니라 서버 인증서로 받아들이고 있는 것 같음.

openssl x509 -in rootCA.crt -text -noout

이 명령어 입력했을 때 나오는 내용 중에

이 두 부분이 서버 도메인이면 안되는 거임

정확히 말하자면 Subject의 CN(인증서의 소유자)가 도메인이면 브라우저는 이 인증서를 루트 인증서가 아니라 서버 인증서로 인식하는데 루트 인증서의 경우 Issuer의 CN(인증서를 발급한 곳(CA))은 Subject의 CN과 같은 이름을 써야하기 때문에 저게 문제가 되고 있음

루트 인증서는 루트 CA에서 발급해야하고 루트 CA가 소유하고 있어야 함!

 

루트 인증서 발급부터 이 인증서로 서명한 서버 인증서 발급까지 다시 해야겠음

 

 

 

 

< 노트북에 루트 인증서 설정해서 브라우저가 신뢰하게 하기(찐막) >

㉮ 루트 CA의 개인키 생성

openssl genrsa -out rootCA.key 4096

㉯ 루트 인증서 발급

openssl req -x509 -new -nodes \
  -key rootCA.key \
  -sha256 -days 1024 \
  -out rootCA.crt

 

이전에 test-paint.local이라는 도메인명을 썼던 CN을 MyLocalCA라고 바꿈

 

• 인증서 내용 출력해서 변경된 거 확인하기

openssl x509 -in rootCA.crt -text -noout

 

 

 

 

㉰ 서버 용 개인키 생성

openssl genrsa -out server.key 2048

 

 

㉱ 서명 요청(CSR) 생성

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

 

 

 

㉲ SAN 설정 파일 수정

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
x509_extensions    = v3_req
prompt             = no

[ req_distinguished_name ]
CN = test-paint.local

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = test-paint.local
IP.1 = 192.168.x.x

 

이랬던 걸 아래와 같이 수정

[ v3_ext ]
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = test-paint.local
IP.1 = 192.168.x.x

 

• 수정하는 이유

1) 첫번째와 같이 req가 쓰인 건 -config 옵션으로 추가하는 설정 파일로, 주로 자체 서명 시 사용 (openssl req)

2) 두번째와 같이 ext가 쓰인 건 -ext 옵션으로 추가하는 확장 설정 파일로, 이미 생성된 CSR을 CA가 서명할 때 사용 (oppenssl x509)

3) 지금은 루트 인증서로 서명한 CSR을 사용할 예정이므로 확장 설정 파일의 내용을 따라야 함.

 

실험해보기

이 시도 전에 req가 쓰인 설정 파일을 썼음

브라우저가 루트 인증서를 인식 못하는 데 이 파일도 한 몫 했을지 궁금함

그래서 저 파일을 수정하지 않았을 경우와 수정했을 경우 차이가 있을지 확인해보려고 함

 

1) SAN 파일 수정 x

아쒸 -ext 옵션은 설정 파일에 v3_ext 섹션이 있어야 해서 에러나고 -ext 옵션을 -config로 수정했더니 openssl x509 명령어로는 -config 옵션을 쓸 수 없대서 에러남 

 

openssl req 명령어로는 자체 서명 인증서가 만들어지기 때문에 이 실험은 종료합니다 땅땅

 

 

㉳ 서명 요청(CSR)으로 로컬 CA(인증 기관)가 서명한 인증서 생성

openssl x509 -req -in server.csr \
  -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \
  -out server.crt -days 825 -sha256 \
  -extfile ext.cnf -extensions v3_ext

 

 

㉴ 내 노트북에 루트 인증서 전송 후 신뢰하는 루트 인증 기관 인증서에 넣기

sftp로 받아서 "컴퓨터 인증서 관리"에서 인증서 항목 우클릭 -> "모든 작업" - "가져오기" 클릭 후 인증서 가져옴

 

이번에는 아까와 달리 도메인으로 표시되지 않고 있음

 

 

㉵ 브라우저에서 확인해보기

안됨

openssl s_client -connect test-paint.local:443 -showcerts

위 명령어로 현재 사용 중인 인증서를 확인해봄

내가 만든 인증서가 사용되지 않고 있는 것을 확인함

시크릿모드에서 들어가도 마찬가지임...

 

 

 

아무래도 내 인증서보다 기본 인증서를 우선하고 있는 것 같아서 기본 ssl 설정 파일을 비활성화 하고 내 서버 전용 ssl 설정 파일을 새로 만들기로 함

 

 

㉶ test-paint.local.conf 설정 파일 만들고 아파치 설정 로드

• /etc/apache2/sites-available/test-paint.local.conf

<VirtualHost *:443>
    ServerName test-paint.local
    ServerAdmin webmaster@test-paint.local

    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/server.crt
    SSLCertificateKeyFile /etc/ssl/private/server.key

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

 

• 활성화

sudo a2ensite test-paint.local.conf

 

• 기존 ssl 설정 파일 비활성화

sudo a2dissite default-ssl.conf

 

• 설정 리로드

sudo systemctl reload apache2

 

• 확인 1

openssl s_client -connect test-paint.local:443 -showcerts

 

에러 뭐시기가 불안하지만 일단 내가 설정한 인증서 내용은 잘 뜨고 있음

 

에러 뭐시기

• openssl s_client 작동 방식

원격 서버에 SSL/TLS 연결을 수동으로 시도

그 연결에 대한 인증서 정보, 체인, 암호화 방식 등 디버깅 용 정보 출력

 

1) 서버에 SSL/TLS 연결을 요청(Client Hello)해서 서버에서 보내준 인증서를 받음

2) 그 인증서랑 클라이언트 측에 있는 루트 인증서를 비교해야 하는데 가상머신의 신뢰할 수 있는 인증 기관에 루트 인증서를 등록하지 않음(/etc/ssl 디렉토리에만 저장되어 있음)

3) 클라이언트는 서버가 보내준 인증서의 유효성을 검증할 수 없어서 에러 출력

 

• verify error:num=20:unable to get local issuer certificate 뜻

발급자 인증서(CA 인증서)를 찾을 수 없음

 

• verify error:num=21:unable to verify the first certificate 뜻

최상위 인증서를 확인할 수 없음

 

• 해결법

 

1) 가상머신의 신뢰할 수 있는 인증 기관 목록에 루트 인증서 복사

sudo cp rootCA.crt /usr/local/share/ca-certificates/rootCA.crt

 

2) CA 목록 업데이트

sudo update-ca-certificates

 

3) 확인

openssl s_client -connect test-paint.local:443 -showcerts

(그밖에 위 명령어에 아예 rootCA.crt를 포함시키는 방법이나 인증서 검증을 건너뛰는 방법도 있는 듯함. api나 프록시 서버와 데이터 주고받을 때 일일이 인증서 설정하기 거시기하면 검증을 건너뛰는가 봄. 그럼 위장 서버에 대한 검증도 없으려나?)

 

error 부분 사라짐

 

루트 인증서 설정하기 전

설정한 후

 ?

파이어폭스는 다른 브라우저들이랑 다르게 운영체제의 루트 인증서 저장소를 사용하지 않는다고 함..

이 브라우저가 서버를 신뢰하게 하려면 파이어폭스의 자체 루트 저장소에 루트 인증서를 넣어야 함

 

 

• [+] 파이어폭스 https 자체 루트 인증서 설정

1) 파이어폭스 오픈

2) 우측 상단의 三버튼 누르고 검색창에 certificate 또는 인증서 검색

3) 나온 결과 중 인증서 보기 혹은 View Certificates 클릭

4) Authority 탭의 하단에 인증서 가져오기(import) 클릭

5) 파일 경로에서 루트 인증서 선택

6) 웹사이트 식별할 때 이 인증 기관을 신뢰혀

7) 오케 오케

8) 확인

 

역시 호스트머신의 파이어폭스는 버프 스위트의 인증서 때문에 들어갈 수 있었던 건가 봄.. 

 

• 확인 2

 

됨ㅠㅠ

발급 대상에 사이트 도메인이 표시되고 발급 기관에 내가 설정한 로컬 CA의 이름이 표시되고 있음

이후 서버 아이피가 변하면 호스트머신의 /hosts 파일에 설정한 아이피만 수정하면 됨

 

내부망에선 이런 식으로 샤샤샥 한다는 건가....

 

 

< 스마트폰에 루트 인증 기관 설정 >

(갤럭시s9)

1) rootCA.crt 스마트폰으로 옮기기

2) 설정 -> 인증서 검색 -> 디바이스에 저장된 인증서 설치 -> rootCA.crt 선택 -> 완료 터치

3) 본인 인증 (지문인식 등)

4) 인증서 이름 적고 확인

5) "사용자 인증서" 위치에서 등록된 루트 인증서 확인

6) 스마트폰 브라우저에서 사이트 접속 (매핑 안했으므로 아이피 주소를 통해 접속)

스마트폰과 내 서버를 오가는 패킷을 호스트머신에서 캡처한 모습

 

 

 

< 정리 >

1) 정석 흐름

≫ 자체 인증서 발급

㉮ 개인키 + 인증서 동시 생성

㉯ 아파치 SSL 설정 파일 수정

㉰ SSL 모듈 활성화 및 서버 리로드

-> 패킷 암호화는 되지만 브라우저가 사이트를 신뢰하지 않음

 

 

≫ 로컬 CA를 통한 인증서 발급

㉮ 로컬 CA 개인키 생성

㉯ 루트 인증서 발급

㉰ 서버 용 개인키 발급

㉱ 서명 요청(CSR) 생성

㉲ 확장 설정 파일 만들어 두기 (서명 요청에 포함시키기 위함)

㉳ 로컬 CA가 서명 요청에 서명해서 인증서 생성

㉴ 클라이언트 측에 루트 인증서 등록 및 도메인 매핑

 

 

2) 로컬 CA를 통한 HTTPS 적용 시 주의할 점

• 루트 인증서의 CN은 도메인과 다른 이름으로 사용해야 함. 아니면 브라우저가 루트 인증서를 서버 인증서로 받아들일 수 있음.
• openssl x509 명령어를 써야 이미 만든 서명 요청을 통해 루트 CA 서명 인증서가 생성됨 (openssl req 말고)
• openssl x509 명령어를 쓸 땐 SAN 파일에 확장 설정을 써야함.
• 브라우저에 뜨는 인증서가 내가 생성한 게 아니라 서버의 기본 인증서로 사용된다면 서버 기본 ssl 설정 파일 비활성화하고 다른 ssl 설정 파일 생성해서 적용

 

3) 핸드셰이크 과정

 

Client Hello 전에 SYN, ACK 패킷 주고 받으면서 TCP 연결 수립. 이후 TLS 핸드셰이크 진행

• TLS1.3 버전

1	2	3
Client Hello	Server Hello	Client Finished
아래의 정보를 서버에 전송 -> 지원하는 암호 스위트 목록 (암호화 알고리즘 조합) -> 랜덤 값 (Client Random) -> Diffie-Hellman 기반의 키 교환을 위해 클라이언트가 보내는 자신의 키 조각 (KeyShare) -> SNI (접속하려는 도메인 이름)	아래의 정보를 클라이언트에 전송 -> 선택한 암호 스위트 -> 랜덤 값 (Server Random) -> KeyShare (서버 측 디피-헬만 키) -> 디지털 서명이 포함된 서버 인증서 -> 서버 Finished	검증 -> Server Hello 정보 검증 -> 핸드셰이크 종료
*암호 스위트 (Cipher suite) - 대칭키를 교환하는 데 사용되는 알고리즘 - 데이터 암호화하는 데이터 교환 알고리즘 - 메시지 인증 코드 (MAC) 알고리즘 *keyshare 세션 키(대칭키)를 만드는 재료 키 교환 간소화를 위해 사용됨	즉시 인증 + 키 교환 *클라이언트와 서버가 keyshare를 완료하면

 

• TLS1.2 버전

1	2	3
Client Hello	Server Hello	인증서 검증
아래 정보를 서버에 전송 -> 지원하는 TLS 버전 -> 지원하는 암호 스위트 목록 -> 랜덤 값 (Client Random) -> SNI (접속하려는 도메인 이름)	아래 정보를 클라이언트에 전송 -> 선택한 암호 스위트 -> 랜덤 값 (Server Random) -> 서버 인증서 (server.crt)	클라이언트가 서버 인증서 검토 -> 서명한 CA가 신뢰하는 루트 인증 기관 목록에 있는지 -> 인증서가 만료되지 않았는지 -> 도메인이 일치하는지 -> 서명이 유효한지
	*인증서 내 정보* => 서버의 공개키, CN/SAN 등 도메인 정보, 유효기간, 서명한 루트 또는 중간 CA의 정보

 

4	5
Pre-Master Secret 전송	Finished
(RSA 방식) -> Client Random 값을 서버가 준 공개키로 암호화하여 서버에 전송 -> 전송 후 서버가 자기 개인키로 이 값을 복호화 -> 이를 통해 클라이언트와 서버 측에 Client Random + Server Random + Pre-Master Secret 을 조합한 동일한 세션 키 (대칭키) 생성	-> Finished 메시지 교환 -> 세션 키로 암호화된 패킷 송수신

 

***세션키(대칭키) 합의 과정의 차이

≫ TLS1.2     

클라이언트와 서버가 랜덤값을 공유한 뒤 클라이언트에서 Pre-Master Secret 생성 + 공개키로 암호화하고 서버로 전송한 뒤에 서버가 그 값을 복원하여 세션 키 만드는 데 사용

≫ TLS1.3     

클라이언트가 keyshare 값 (공개키 조각)을 전송하고 서버에서는 바로 클라이언트 keyshare 값이랑 서버 keyshare 값이랑 싸바싸바해서 Shared Secret 생성, 이후 클라이언트도 keyshare 전달받고 Shared Secret 생성해서 세션 키 만드는 데 사용

 

랜덤값 공유 과정 등이 빠진 tls1.3 방식이 훨씬 암호화가 빠름

(파고들면 끝도 없구만...)

 

 

 

 

---

 

 

 

 

 

https://jinyeanseok.tistory.com/95

[SSL] 프로젝트에 HTTPS 통신을 위한 SSL 설정(RSA암호화)

 

 

https://ssunw.tistory.com/entry/Linux-HTTPS-%EC%9D%B8%EC%A6%9D%EC%84%9C-%EB%B0%9C%EA%B8%89

[Linux] HTTPS 인증서 발급

 

 

https://cert.crosscert.com/%EC%9C%88%EB%8F%84%EC%9A%B0windows-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-pc%EC%97%90%EC%84%9C-%EB%A3%A8%ED%8A%B8%EC%9D%B8%EC%A6%9D%EC%84%9C-%EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95/

윈도우Windows 운영체제 PC에서 루트인증서 설치방법 - SSL 인증서 발급,종류,가격비교 | 한국전자인

 

https://docs.openssl.org/master/man1/openssl-genrsa/

openssl-genrsa - OpenSSL Documentation