당신은 주제를 찾고 있습니까 “사설 인증서 – [월요지식회] EP.28 공인인증서 폐지! 사설인증서 삼국지시대 개막?!(Feat. 통신. 페이. 은행)“? 다음 카테고리의 웹사이트 ppa.maxfit.vn 에서 귀하의 모든 질문에 답변해 드립니다: https://ppa.maxfit.vn/blog. 바로 아래에서 답을 찾을 수 있습니다. 작성자 마니버니 이(가) 작성한 기사에는 조회수 6,479회 및 좋아요 13개 개의 좋아요가 있습니다.

사설 인증서 주제에 대한 동영상 보기

여기에서 이 주제에 대한 비디오를 시청하십시오. 주의 깊게 살펴보고 읽고 있는 내용에 대한 피드백을 제공하세요!

d여기에서 [월요지식회] EP.28 공인인증서 폐지! 사설인증서 삼국지시대 개막?!(Feat. 통신. 페이. 은행) – 사설 인증서 주제에 대한 세부정보를 참조하세요

#월요지식회 #공인인증서 #액티브X
오랫동안 우리의 온라인 소비에 장벽처럼 작용하던
공인인증서가 폐지된다는 소식! 다들 접하셨나요?
누구나 한 번쯤은 온라인 쇼핑할 때 공인인증서 발급받고,
액티브X 설치하고, 컴퓨터 다시 키고, 다시……….를 겪어 보셨을 겁니다.
온라인을 통해 등본 등 증명서 발급이나 금융업무를 하려면
반드시 거쳐야 했던 공인인증서의 관문이 무려 21년 만에 폐지됩니다.
그동안 우리를 괴롭혔던 공인인증서에 대해
월요일의 지식맛집 월요지식회에서 알아보겠습니다!
#월요지식회 #마니버니 #공인인증서 #사설인증서 #인증서 #엑티브X #ActiveX #PASS #네이버페이 #카카오페이 #KB모바일인증서 #모바일인증서 #천송이코트 #별그대 #KB스타뱅킹 #KB국민은행 #국민은행

사설 인증서 주제에 대한 자세한 내용은 여기를 참조하세요.

자체 서명 인증서 만들기 – :::: 곰탱푸닷컴 ::::

HTTPS를 사용하려면 공인 인증서 또는 사설 인증서를 적용해야 한다. 공인 인증서를 사용하는 방법은 크게 두 가지이다. 하나는 공인 인증기관을 통해 …

+ 자세한 내용은 여기를 클릭하십시오

Source: www.bearpooh.com

Date Published: 11/30/2022

View: 8346

SSL 통신 이슈 파악을 위한 사설 인증서 사용과 검증 방법

사설 인증서를 가지고 curl 을 수행하니, 정상적으로 SSL Handshake가 이루어지고 연결이 되는 것을 확인해봅니다. 우리가 원격지의 Server와 SSL …

+ 자세한 내용은 여기를 클릭하십시오

Source: tech.osci.kr

Date Published: 12/27/2022

View: 2142

사설인증서 분석 – 브런치

오늘부터 전면 폐지되는 공인인증서(사실은 공동인증서로 이름만 바뀌고 다른 사업자가 뛰어들 수 있게 개방형으로 바뀌는 거지만). 그러다보니 사설 …

+ 여기를 클릭

Source: brunch.co.kr

Date Published: 1/26/2022

View: 763

한국정보인증, 사설인증서 인증시스템 구축 시장 본격 진출

국내 최초로 공동인증서, 사설인증서(S-PASS인증서비스) 전자서명인증사업자 인정을 모두 획득한 기술력과 컨설팅 노하우를 앞세운다. 한국정보인증은 …

+ 여기에 표시

Source: www.etnews.com

Date Published: 12/13/2022

View: 4828

자체 서명 사설 SSL 인증서 만들기 – 시스템 엔지니어의 세상

사설 인증서를 만들고 웹 서버 설정 후 브라우저에서 사용하기까지 전체 과정을 살펴보고, 실습을 통해 쉽게 적용하고 사용할 수 있습니다.

+ 여기에 자세히 보기

Source: www.runit.cloud

Date Published: 2/18/2022

View: 8989

[금융 D-택트] 사설인증서 만드는 은행, 성공 방정식은?

이밖에도 빅테크인 네이버·카카오·토스도 자체 인증서를 갖고 있습니다. 사설인증서는 즉 전자서명서비스로 대면에서 비대면으로 거래가 차츰 이동하는 …

+ 여기에 보기

Source: zdnet.co.kr

Date Published: 8/5/2021

View: 1408

“빅테크보다 더 편하게” 사설인증서 뛰어드는 시중은행

[데일리임팩트 임은빈 기자] ‘천송이 코트’ 해프닝을 낳으며 역사 속으로 사라진 공인인증서 제도를 대체하기 위해 주요 시중은행들이 사설인증서 …

+ 여기에 보기

Source: www.dailyimpact.co.kr

Date Published: 12/4/2022

View: 9553

공동인증서, 금융인증서, 토스인증서 뭐가 다른가요?

토스인증서는 정부의 보증을 받은 사설인증서로, 본인확인기관 라이센스와 전자서명인증사업자 라이센스를 모두 획득한 유일한 사업자예요. 그렇기 때문에 …

+ 여기에 자세히 보기

Source: blog.toss.im

Date Published: 1/28/2022

View: 8439

사설 인증서 생성하기 – 상구리의 기술 블로그

사설 인증서 생성. 루트 인증서 생성. openssl ecparam -out rootCA.key -name prime256v1 -genkey. Copy openssl req -new -sha256 -key rootCA.key …

+ 여기에 표시

Source: www.skyer9.pe.kr

Date Published: 12/29/2021

View: 9570

주제와 관련된 이미지 사설 인증서

주제와 관련된 더 많은 사진을 참조하십시오 [월요지식회] EP.28 공인인증서 폐지! 사설인증서 삼국지시대 개막?!(Feat. 통신. 페이. 은행). 댓글에서 더 많은 관련 이미지를 보거나 필요한 경우 더 많은 관련 기사를 볼 수 있습니다.

---

주제에 대한 기사 평가 사설 인증서

• Author: 마니버니
• Views: 조회수 6,479회
• Likes: 좋아요 13개
• Date Published: 2020. 6. 29.
• Video Url link: https://www.youtube.com/watch?v=wEwJ03eA38c

:::: 곰탱푸닷컴 ::::

반응형

Docker로 테스트하거나 실서비스 운영을 하다보면 HTTPS 접근 방법에 대한 고민을 하게 된다.

HTTPS를 사용하려면 공인 인증서 또는 사설 인증서를 적용해야 한다.

공인 인증서를 사용하는 방법은 크게 두 가지이다.

하나는 공인 인증기관을 통해 발급한 인증서를 적용하는 것이고, 다른 하나는 무료 공인 인증서인 Let’s Encrypt를 사용하는 것이다.

공인 인증 기관에서 발급 받는 인증서는 가장 교과서적인 방법이지만 비싸서 개인이 운영하기에는 부담이 된다.

물론 회사에서 운영하는 서비스는 회사 비용을 사용해서 공인 인증서를 발급 받는 것을 권장한다.

개인의 경우 무료로 제공하는 공인 인증서인 Let’s Enrypt를 사용하는 방법이 있다.

90일 마다 갱신해야 하므로 번거롭다는 단점이 존재하며, 구글링하면 자동 갱신하는 방법이 많이 있으니 참고하면 도움이 된다.

시놀로지 NAS에서 Let’s Encrypt 인증서 발급 받는 방법은 아래 포스팅을 참고한다.

일반 서버 환경에서 Let’s Encyrpt 인증서를 발급 받는 방법은 아래 포스팅 참고한다. 정리가 아주 잘 되어 있다.

Docker로 특정 시스템을 테스트를 하거나 내부에서만 사용할 목적으로 운영하는 경우, 자체 서명한 사설 인증서 적용하는 방법도 있다.

사설 인증서이기 때문에 브라우저에서 경고 메시지가 출력되지만, 개발과 테스트 목적인 경우는 큰 문제가 되지 않는다.

공인 인증서를 적용하는 것은 외부와 통신이 필요하거나 공식으로 서비스를 오픈할 때 고민하면 된다.

순서는 다음과 같다.

루트 인증서의 키(KEY) 생성 루트 인증서의 인증 서명 요청 (CSR) 생성 루트 인증서의 인증서 (CRT) 생성 사설 인증서의 키(KEY) 생성 사설 인증서의 인증 서명 요청 (CSR) 생성 사설 인증서의 인증서 (CRT) 생성 사설 인증서의 JKS (Java Keystroke) 생성 (Optional)

openssl 설치

일반적으로 Ubuntu 20.04 환경에서는 설치되어 있어 새로 설치할 필요는 없다.

아래 명령으로 설치 여부와 버전을 확인한다.

$ openssl version OpenSSL 1.1.1f 31 Mar 2020

현재 시스템에는 2020년 3월 1일에 배포 된 1.1.1f 버전이 설치되어 있다.

해당 정보가 확인되지 않으면 아래 명령어로 설치를 진행한다.

$ sudo apt update $ sudo apt install openssl

루트 인증서 (CA)

먼저 인증서 파일들을 저장하기 위한 폴더를 만들고 해당 폴더로 이동한다.

$ mkdir ~/certs $ cd ~/certs

앞으로 모든 작업은 ~/certs 폴더에서 진행한다.

인증서를 생성할때 비밀번호 (key pass phrase)를 입력해야 한다.

경우에 따라 인증서를 사용하는 설정 파일에 비밀번호를 입력해야 하므로 공개해도 되는 문자열로 입력한다.

여기서는 testcerts를 사용한다.

루트 인증서 키 만들기

루트 인증서를 생성하는데 사용할 키 (key)를 생성한다.

다음과 같이 실행한다.

# root ca 키생성 $ openssl genrsa -aes256 -out rootca.key 2048

RSA 2048로 키를 생성하고 aes256 암호화 기법으로 암호화 하여 rootca.key 파일로 저장

2048은 RSA 키 생성 길이를 의미하며 1024, 4096도 된다. 키 값의 길이가 길 수록 보안성이 우수하다.

루트 인증서 CSR(인증 서명 요청) 만들기

csr 타입의 루트 인증서 서명 요청 파일을 만든다.

앞서 생성한 루트 인증서 키 파일을 사용한다.

# root ca 요청서 만들기 $ openssl req -new -key rootca.key -out rootca.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —– Country Name (2 letter code) [XX]:KR State or Province Name (full name) []:GG # 경기도 Locality Name (eg, city) [Default City]:SN # 성남시 Organization Name (eg, company) [Default Company Ltd]:test # 조직/회사명 입력 Organizational Unit Name (eg, section) []:unit # 부서명 입력 Common Name (eg, your name or your server’s hostname) []:test # 서버 이름 입력 Email Address []:[email protected] # 이메일 주소 Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: testcerts # 공개되도 상관 없는 암호 입력 An optional company name []: # 비워놓고 엔터 (다른 이름 부여 가능)

루트 인증서 (CRT) 만들기

앞서 생성한 루트 인증서의 Key (키)파일과 CSR (인증 서명 요청) 파일을 사용하여 루트 인증서를 생성한다.

$ openssl x509 -req -days 3650 -set_serial 1 -in rootca.csr -signkey rootca.key -out rootca.crt Signature ok subject=C = KR, ST = GG, L = SN, O = test, OU = unit, CN = test, emailAddress = [email protected] Getting Private key

암호를 요구하는 경우 CSR 파일을 생성할 때 입력한 암호를 입력한다.

-days 3650 옵션을 부여했으므로 유효 기간은 10년이다.

사설 인증서

이제 웹 서버에서 사용할 사설 인증서를 생성한다.

사설 인증서 키 만들기

사설 인증서를 생성하는데 사용할 키 (key)를 생성한다. 루트 인증서 키 생성과 동일하다.

다음과 같이 실행한다.

# 사설 인증서 키생성 $ openssl genrsa -aes256 -out 서버IP.key 2048

RSA 2048로 키를 생성하고 aes256 암호화 기법으로 암호화 하여 파일로 저장

2048은 RSA 키 생성 길이를 의미하며 1024, 4096도 된다. 키 값의 길이가 길 수록 보안성이 우수하다.

아래 명령을 사용하여 키 암호를 제거한다.

# 키 암호 제거 $ openssl rsa -in 서버IP.key -out 서버IP.np.key

사설 인증서 CSR(인증 서명 요청) 만들기

csr 타입의 루트 인증서 서명 요청 파일을 만든다.

앞서 생성한 사설 인증서 키 파일을 사용한다.

루트 인증서 서명 요청 파일과 동일한 화면이 출력되는데 동일하게 입력한다.

# 요청서 만들기 $ openssl req -new -key 서버IP.np.key -out 서버IP.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —– Country Name (2 letter code) [XX]:KR State or Province Name (full name) []:GG # 경기도 Locality Name (eg, city) [Default City]:SN # 성남시 Organization Name (eg, company) [Default Company Ltd]:test # 조직/회사명 입력 Organizational Unit Name (eg, section) []:unit # 부서명 입력 Common Name (eg, your name or your server’s hostname) []:test # 서버 이름 입력 Email Address []:[email protected] # 이메일 주소 Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: testcerts # 공개되도 상관 없는 암호 입력 An optional company name []: # 비워놓고 엔터 (다른 이름 부여 가능)

사설 인증서 (CRT) 만들기

앞서 생성한 사설 인증서의 Key (키)파일과 CSR (인증 서명 요청) 파일, 그리고 루트 인증서의 CRT 파일을 사용하여 사설 인증서를 생성한다.

# 인증서 만들기 $ openssl x509 -req -days 3650 -extensions v3_user -in 서버IP.csr -CA rootca.crt \ -CAcreateserial -CAkey rootca.key -out 서버IP.crt

암호를 요구하는 경우 CSR 파일을 생성할 때 입력한 암호를 입력한다.

-days 3650 옵션을 부여했으므로 유효 기간은 10년이다.

생성 된 인증서 정보 확인은 다음 명령을 사용한다.

# 확인 $ openssl x509 -text -in 서버IP.crt

Java Key Stroke File 생성

Jenkins와 Nexus 같은 일부 Java 기반 시스템의 경우 JKS (Java Keystroke) 포맷을 사용하므로 변경해야 한다.

PEM 파일로 변경

생성한 사설 인증서의 CRT 파일을 PEM 파일로 변경한다.

## crt를 pem으로 변경 openssl x509 -in 서버IP.crt -out 서버IP.pem -outform PEM

PFX 파일 생성

생성 된 PEM 파일을 사용하여 PFX 파일을 생성한다.

## pfx 파일 생성 # 아래 명령 실행 후 password를 입력해야 하는데, 이후 jetty 설정 파일에 평문으로 기입하는데 사용한다. # 서버에 접속 가능한 다른 사용자가 보아도 되는 password를 입력한다. $ openssl pkcs12 -export -name 서버IP -in 서버IP.pem -inkey 서버IP.key -out 서버IP.pfx # password 입력

JKS 파일 생성

생성 된 pfx 파일을 사용하여 jks 파일을 생성한다.

## jks 파일 생성 $ keytool -importkeystore -srckeystore 서버IP.pfx -srcstoretype pkcs12 \ -destkeystore 서버IP.jks -deststoretype jks # password 입력 ## keystore.jks 파일 생성 $ cp 서버IP.jks keystore.jks

인증서 사용

이제 생성 된 인증서를 사용하여 각 서비스의 HTTPS 설정 적용에 사용하면 된다.

사설 인증서의 CRT 파일과 Key 파일을 주로 사용하며, 경우에 따라 JKS 파일을 사용하기도 한다.

각 서비스의 인증서 사용 방법에 맞춰 사용하면 된다.

이 부분은 적용하고자 하는 서비스의 기술 문서를 참고한다.

최초 접속시 브라우저에서 빨간 화면을 출력하는 것은 사라진다.

그러나 사설 인증서이므로 브라우저의 주소창에 아래와 같이 빨간 경고 표시로 안전하지 않음으로 표시 된다.

내부에서만 운영하거나 테스트 목적인 경우 이 정도만 적용해도 충분히 활용 가능하다.

반응형

SSL 통신 이슈 파악을 위한 사설 인증서 사용과 검증 방법

1. 공유가 필요한 이유

안녕하세요. 오픈소스컨설팅에서 미들웨어 담당하고 있는 김동현입니다.

오늘은, WEB/WAS 에서 자주 언급되고 사용되는 SSL 인증서의 기본 학습을 위한 테스트를 진행해볼까 합니다.

최근에 고객사에서 사용하던 SSL 인증서가 만료시점이 되어, 파일 교체를 하였다고 합니다.

교체한 인증서와 기존에 사용하고 있던 인증서 내용이 다르지 않고, Expire (만료기간)만 갱신된 동일한 인증서라면 별다른 트러블이 발생하지 않겠지만, 어떠한 문제가 발생을 하였는지 SSL 인증 거부로 통신이 되지 않는 이슈가 있었습니다.

이러한 상황에 맞닥뜨렸을 때, 기본적으로 어떠한 방법을 통해 SSL 인증서에 문제가 없는지 테스트를 진행해보겠습니다.

이슈가 발생한 고객사의 환경은, 우리가 많이 어디선가 접한, 일반적인 REST API 호출 부분에서의 SSL 인증 문제 였습니다. WAS AP(Tomcat) 에서 REST API 를 이용하여 Remote AP(Apache)를 호출합니다. WAS AP(Tomcat) / Remote AP(Apache) 양쪽간의 SSL 인증서가 동일하게 교체 되었지만 API 호출 시 SSL 인증 거부 이슈 발생 했습니다.

다음의 Step 을 진행하며, SSL 인증서가 유효하게 적용되고 동작하고 있는지 검증하는 것을 알 수 있습니다. 사설/비-사설 SSL인증서의 검증 방법 등을 확인 사설(Self-Signed) SSL 인증서를 Remote AP(Apache)에 Setup HTTPS 통신을 하며, SSL 인증서 검증 WAS AP(Tomcat)에 SSL 클라이언트 인증서를 Setup. HTTPS 연결을 수행.

2. SSL 인증서 생성

인증서의 생성이 되고, 위치할 CERT 디렉토리를 만들어줍니다.

$ mkdir /tmp/self_signed_cert $ CERT=/tmp/self_signed_cert

2.1 Private Key

$ openssl genrsa -des3 -out ${CERT}/private.key Generating RSA private key, 2048 bit long modulus (2 primes) …….+++++ ……………………………………………………..+++++ e is 65537 (0x010001) Enter pass phrase for /tmp/self_signed_cert/private.key: (dhkim) Verifying – Enter pass phrase for /tmp/self_signed_cert/private.key: (dhkim)

개인키의 패스워드로 dhkim 을 사용했습니다.

패스워드를 사용하지 않으려면 -des3 옵션을 제거 합니다.

2.2 CSR

제가 직접 생성한 (혹은 고객) 인증서는 최상위 기관(root) 에 제출해야 합니다. 최상위 기관(root Certificate Authority; root CA)에서 서명(제출한 인증서를 유효하다고 인증과 같은 절차)을 받기 위해 필요합니다.

$ openssl req -new -key ${CERT}/private.key -out ${CERT}/root.csr \ -subj “/C=KR/ST=Seoul/L=Seocho-gu/O=OSCI/OU=Cloud Migration/CN=dhkim.com”

2.3 Self-Signed

우리가 사용하는 Chrome 과 같은 Browser에는 아래에서 언급하는 신뢰할 수 있는 상위 기관들의 인증서가 이미 포함되어 있습니다. 자체 서명한 인증서를 사용하면, Browser에 설치되어 있는 인증서로 유효한지 확인을 합니다.

위에서 만든 개인키( private.key )와 제출하는 인증 요청서( root.csr )을 가지고, 직접 서명할 수 있습니다. 내 자신이 최상위 기관이 되어, 스스로를 서명하는 것입니다. 이것을 말 그대로 Self-Signed 라고 하며, 해당 인증서를 사용하여 HTTPS 연결을 시도하면 상위 기관(rootCA or intermediate ca) 에서 인증되지 않아 경고가 나타납니다.

$ openssl x509 -req -days 365 \ -in ${CERT}/root.csr \ -signkey ${CERT}/private.key \ -out ${CERT}/dhkim.com.crt —stdout below— Signature ok subject=C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com Getting Private key Enter pass phrase for /tmp/self_signed_cert/private.key: (dhkim)

3. 인증서 적용

Listen 443 Define CERT “/tmp/self_signed_cert” SSLPassPhraseDialog exec:${SRVROOT}/bin/sslpass.sh SSLCertificateFile ${CERT}/dhkim.com.crt SSLCertificateKeyFile ${CERT}/private.key SSLEngine on ServerName dhkim.com DocumentRoot “/tmp/htdocs_ssl” Options None AllowOverride None Require all granted

PC의 hosts 파일에 dhkim.com 을 등록하고, 접속할 수 있습니다.

접속 시 아래와 같이 완료되었습니다.

4. HTTS 테스트

4.1 curl

(1) 기본 인증서 사용

$ curl -v https://dhkim.com * Rebuilt URL to: https://dhkim.com/ * Trying 192.168.56.2… * TCP_NODELAY set * Connected to dhkim.com (192.168.56.2) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS alert, unknown CA (560): * SSL certificate problem: self signed certificate * Closing connection 0 curl: (60) SSL certificate problem: self signed certificate More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

CAfile: /etc/pki/tls/certs/ca-bundle.crt 인증서 파일을 사용하여 dhkim.com 인증을 하려고 합니다. 앞서 우리가 만든 SSL 인증서는, 어떠한 공증된 상위 기관에서 인증해준 것이 아니라 자체 서명(Self-Signed) 하였기 때문에 CA를 알 수 없습니다. 아래가 그 로그입니다.

TLSv1.2 (OUT), TLS alert, unknown CA (560):

SSL certificate problem: self signed certificate

SSL 인증 문제의 원인으로 자체 서명된 인증서로 로그가 출력되었습니다.

정확히는 curl 이 사설 인증서 인지를 알고 있는 것이 아니라, 어디에도 서명(Signed) 되어 있지 않음을 원인으로 알려준 것입니다.

(2) 사설 인증서 사용

사설 인증서를 가지고 curl 을 수행하니, 정상적으로 SSL Handshake가 이루어지고 연결이 되는 것을 확인해봅니다. 우리가 원격지의 Server와 SSL 통신을 수행해야 할 때, 가지고 있는 인증서가 유효한지 curl 의 간단한 명령으로도 확인이 가능하다는 것을 알 수 있습니다.

$ curl -v https://dhkim.com –cacert ${CERT}/dhkim.com.crt * Rebuilt URL to: https://dhkim.com/ * Trying 192.168.56.2… * TCP_NODELAY set * Connected to dhkim.com (192.168.56.2) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /tmp/self_signed_cert/dhkim.com.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, [no content] (0): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=KR; ST=Seoul; L=Seocho-gu; O=OSCI; OU=Cloud Migration; CN=dhkim.com * start date: May 10 09:48:47 2022 GMT * expire date: May 10 09:48:47 2023 GMT * common name: dhkim.com (matched) * issuer: C=KR; ST=Seoul; L=Seocho-gu; O=OSCI; OU=Cloud Migration; CN=dhkim.com * SSL certificate verify ok. * TLSv1.3 (OUT), TLS app data, [no content] (0): > GET / HTTP/1.1 > Host: dhkim.com > User-Agent: curl/7.61.1 > Accept: */* > * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS app data, [no content] (0): < HTTP/1.1 200 OK < Date: Wed, 11 May 2022 04:08:14 GMT < Server: Apache < Last-Modified: Wed, 11 May 2022 03:47:47 GMT < ETag: "c-5deb44dfe095d" < Accept-Ranges: bytes < Content-Length: 12 < Content-Type: text/html < hello world * Connection #0 to host dhkim.com left intact CAfile: /tmp/self_signed_cert/dhkim.com.crt 인증서를 지정할 수 있습니다. 11~23 Line SSL handshake 가 정상적으로 문제없이 일어났습니다. 24 Line TLSv1.4 버전 프로토콜 / 암호화 알고리즘 로그가 확인됩니다. 26~32 Line subject(보안 대상; 웹서버)와 issuer(발급자; 인증서 증명자)의 정보입니다. (3) 사설 인증서 사용 (download ssl) 원격지의 SSL 인증서를 역으로 다운로드 받아, 활용하는 방법도 해볼 수 있습니다. 굳이 접속을 하기 위해 SSL 인증서를 손에 쥐고 있을 필요가 없습니다. $ openssl s_client -servername dhkim.com -connect 192.168.56.2:443 -showcerts > ${CERT}/download_dhkim.com.crt $ ls -rtl ${CERT}/download_dhkim.com.crt -rw-rw-r–. 1 dhkim dhkim 6220 5월 11 13:15 /tmp/self_signed_cert/download_dhkim.com.crt

openssl 명령으로, 원격지의 SSL 인증서를 다운로드 받았습니다.

기존에 우리가 가지고 있던 원본 SSL 인증서와, 방금 다운로드 받은 SSL 인증서는 무슨 차이가 있길래, 용량도 내용의 길이면도 차이가 있을까요?

$ ls -rtl ${CERT}/*crt -rw-rw-r–. 1 dhkim dhkim 1237 5월 10 18:48 /tmp/self_signed_cert/dhkim.com.crt -rw-rw-r–. 1 dhkim dhkim 6220 5월 11 13:15 /tmp/self_signed_cert/download_dhkim.com.crt

용량도, 내용도 달라보이지만 사실상 차이는 없습니다. 내용을 비교하면 download_dhkim.com.crt 파일이 좀 더 방대하지만,

BEGIN CERTIFICATE 으로 시작하여 END CERTIFICATE 으로 끝나는 사이의 암호화된 인증서 정보는 같습니다. 다른 내용은 필요 없고, 암호화된 인증서 정보만을 가지고 SSL 인증을 수행하기 때문입니다.

파일이 좀 더 방대하지만, 으로 시작하여 으로 끝나는 사이의 암호화된 인증서 정보는 같습니다. 다른 내용은 필요 없고, 암호화된 인증서 정보만을 가지고 SSL 인증을 수행하기 때문입니다. 다운로드 받은 인증서로 연결을 수행해봅시다.

$ curl -v https://dhkim.com –cacert ${CERT}/download_dhkim.com.crt * Rebuilt URL to: https://dhkim.com/ * Trying 192.168.56.2… * TCP_NODELAY set * Connected to dhkim.com (192.168.56.2) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /tmp/self_signed_cert/download_dhkim.com.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, [no content] (0): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=KR; ST=Seoul; L=Seocho-gu; O=OSCI; OU=Cloud Migration; CN=dhkim.com * start date: May 10 09:48:47 2022 GMT * expire date: May 10 09:48:47 2023 GMT * common name: dhkim.com (matched) * issuer: C=KR; ST=Seoul; L=Seocho-gu; O=OSCI; OU=Cloud Migration; CN=dhkim.com * SSL certificate verify ok. * TLSv1.3 (OUT), TLS app data, [no content] (0): > GET / HTTP/1.1 > Host: dhkim.com > User-Agent: curl/7.61.1 > Accept: */* > * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS app data, [no content] (0): < HTTP/1.1 200 OK < Date: Wed, 11 May 2022 04:16:06 GMT < Server: Apache < Last-Modified: Wed, 11 May 2022 03:47:47 GMT < ETag: "c-5deb44dfe095d" < Accept-Ranges: bytes < Content-Length: 12 < Content-Type: text/html < hello world * Connection #0 to host dhkim.com left intact 전혀 문제 없이, SSL Handshake 수행됩니다. 4.2 openssl (1) 기본 인증서 사용 $ openssl s_client -servername dhkim.com -connect 192.168.56.2:443 CONNECTED(00000003) depth=0 C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com verify error:num=18:self signed certificate verify return:1 depth=0 C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com verify return:1 --- Certificate chain 0 s:C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com i:C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com --- Server certificate -----BEGIN CERTIFICATE----- MIIDYzCCAksCFDfIh7j8xqsFYz9suq3XIC9rAG6PMA0GCSqGSIb3DQEBCwUAMG4x CzAJBgNVBAYTAktSMQ4wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJU2VvY2hvLWd1 MQ0wCwYDVQQKDARPU0NJMRgwFgYDVQQLDA9DbG91ZCBNaWdyYXRpb24xEjAQBgNV BAMMCWRoa2ltLmNvbTAeFw0yMjA1MTAwOTQ4NDdaFw0yMzA1MTAwOTQ4NDdaMG4x CzAJBgNVBAYTAktSMQ4wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJU2VvY2hvLWd1 MQ0wCwYDVQQKDARPU0NJMRgwFgYDVQQLDA9DbG91ZCBNaWdyYXRpb24xEjAQBgNV BAMMCWRoa2ltLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYY RPC8/lh6TPsWmhqgtpb5GUAfODUahfkkklR0pUafCPpVyfAoBKzMcYgEU8kK0ETf T8jF9LrforRAa6rrm7e2I3N93TzUgypRAdJeoFC1Eg1YpchHGHkoDVrMqMZdCjVZ +2QR0E8B16RedzCY55ctb0dCHckoD4nnzwvm6HInpFK6DrZBxdbEh1Dr8hiEsWtH bYeHGFWc/ugmAlVzuQLNevInKS9pUFglb7yxYpkVI4wf6C/Hyf0Wba34yBcGLtbr cF32TJrp12wAq1D16jUX1fDwiiq6P9mo0Xxw2bza17PyzeV++i2DszRjhgh9A1RE 6A/ZX15gtgYY4Bsp4e8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAgwp7vJb24g6r 78VPi3UwEkgSRbSnc9yK2KlObc2xtwK5TbibeIPdbkw5vPj9tieCgNyvKfpWnIni /CvDILdaRnAMcCbP2O3cNBK/xQDvL1pw3GMzWaZvPgqGNNQ1GOD5FzPnBXniOG8T OsY54KG31zLp7/JslJ7CmtfFFXRRMMYIRXBMJdNNZE4n4j6+SNOdhFlxAqGevrzE qKAndFkRsr//le62ddeegVZdiZiEZfbPNx3ebfs98VXV7HyvsDt3H/oRGXsBF1gl DyqobfbdovazynOi/NHZN2JJEaZREVM7itozp26cIfmgEXwWkGEocPZOGMAQYDo2 5fq8KSWaKg== -----END CERTIFICATE----- subject=C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com issuer=C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 1431 bytes and written 387 bytes Verification error: self signed certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 18 (self signed certificate) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 9EF9BB21AB914D0155A71BC146167828D773705EFF8B04608CC9C7EAD688C656 Session-ID-ctx: Resumption PSK: 96F5690C7A6D733E7CB1A0F5DD595908F8A50F1D7209D831FBF5F198228DB4689EE7097958AAA599527BA18883A45E46 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 1f be 43 bb 42 73 6a cf-2a cb cc 05 fc 02 6d aa ..C.Bsj.*.....m. 0010 - c7 68 0c b6 bc 20 ae e4-96 38 a0 82 3c 36 a3 96 .h... ...8..<6.. 0020 - 7a 2f 7b 92 b2 ce 7c 68-ad b1 3a b3 6d 6f 7e 09 z/{...|h..:.mo~. 0030 - 56 61 c5 65 e4 91 0c e3-b0 47 58 c4 e8 95 f7 6b Va.e.....GX....k 0040 - 0a f2 4e e1 b4 bf 9b 71-6d 10 c7 21 99 6d 94 62 ..N....qm..!.m.b 0050 - 02 b9 b7 34 5e 5c dd 55-69 95 de 3c 5f bd 81 e2 ...4^\.Ui..<_... 0060 - f9 06 29 bf f4 85 0c 96-e3 87 d5 0a 08 14 9d b2 ..)............. 0070 - 72 2c 22 40 b2 4e ad 12-55 82 4a 70 35 cf 76 cb r,"@.N..U.Jp5.v. 0080 - d8 ac 34 d3 c5 ce fe 04-9b d3 31 66 0b 55 3b b3 ..4.......1f.U;. 0090 - 40 e1 33 45 2e ac 95 da-9d 60 a1 78 f5 62 f4 3a @.3E.....`.x.b.: 00a0 - 8d 67 2f 3a de 55 cc 40-08 81 df 2f 2c 57 4f 89 .g/:.U.@.../,WO. 00b0 - 6b 7b 45 8b 0a df e4 11-c6 db f0 b2 9f 82 76 4c k{E...........vL 00c0 - c0 53 7f 6a 23 7d 23 b3-73 c4 41 4d f6 98 5a 43 .S.j#}#.s.AM..ZC 00d0 - 31 dd 58 31 d2 0b ab 81-90 5c 67 44 70 ec 19 a0 1.X1.....\gDp... 00e0 - 99 cc 07 99 5b e1 7d 11-a1 5f bf f5 4f e8 b3 2a ....[.}.._..O..* Start Time: 1652242972 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) Extended master secret: no Max Early Data: 0 --- read R BLOCK --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 9FFF3FB5D62CB380CC9836ED892D93A84B4D11B64B25A100DBFA5E44612B20F2 Session-ID-ctx: Resumption PSK: AE2689A89A2E0F14B5041F9CDA86E749663469A000ACD4D834BA40772D3A25B9D887F6C12672B251A906F4CC0D7D67AC PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 1f be 43 bb 42 73 6a cf-2a cb cc 05 fc 02 6d aa ..C.Bsj.*.....m. 0010 - 3f fb af c5 b8 3e 39 1f-b7 a5 48 85 e4 cc ae 36 ?....>9…H….6 0020 – 66 22 f8 fc 25 e7 38 c7-2f 1d 8b 0a ba 8c 92 cd f”..%.8./……. 0030 – af 02 55 3d 02 29 ea 1a-cb a4 7e bc b4 21 74 82 ..U=.)….~..!t. 0040 – 6a 41 45 67 a9 1c 4f eb-a2 02 81 bd 65 cf da 59 jAEg..O…..e..Y 0050 – 25 bc 99 3e 0e aa 1e 6c-de 7a 77 0a 5d 98 96 96 %..>…l.zw.]… 0060 – 39 85 18 df dc 8d 53 52-73 c6 0b 40 f1 4f 23 fa 9…[email protected]#. 0070 – ab df 68 da 09 84 2f 1e-47 13 3f ba 4b c6 c1 a4 ..h…/.G.?.K… 0080 – dd 23 bb ce 83 35 98 a1-3e 3d 6e dc 2e cb 71 fe .#…5..>=n…q. 0090 – 98 51 63 ce aa 61 98 38-ee 82 84 8a a3 97 28 a1 .Qc..a.8……(. 00a0 – 22 88 08 53 cb 3d 59 78-09 c6 ea 8a 71 c0 ee cc “..S.=Yx….q… 00b0 – a0 6c 71 bc 0b 26 5a 52-65 3e 77 9e b3 3c b6 80 .lq..&ZRe>w..<.. 00c0 - d4 fb 98 9b c2 e9 a4 e0-14 49 c1 ae 42 8d a2 5f .........I..B.._ 00d0 - 6b 0d b7 94 f3 42 50 5d-6f 98 33 e8 1f 8a e7 2e k....BP]o.3..... 00e0 - 75 cc a8 52 64 cd d7 bd-c2 59 c9 b5 a5 ac ea e1 u..Rd....Y...... Start Time: 1652242972 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) Extended master secret: no Max Early Data: 0 --- read R BLOCK HTTP/1.1 400 Bad Request Date: Wed, 11 May 2022 04:22:52 GMT Server: Apache Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1

Bad Request

Your browser sent a request that this server could not understand.

closed

openssl 을 이용하면, 기본적으로 SSL 연결은 정상적으로 수행되지만,

Verification error: self signed certificate 와 같이 경고성 메시지를 출력해주고 있습니다.

(2) 사설 인증서 사용

위에서 해본 것처럼, SSL 인증서를 지정하여 확인해볼 수 있습니다.

$ openssl s_client -servername dhkim.com -connect 192.168.56.2:443 -CAfile ${CERT}/dhkim.com.crt CONNECTED(00000003) depth=0 C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com verify return:1 — Certificate chain 0 s:C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com i:C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com — Server certificate —–BEGIN CERTIFICATE—– MIIDYzCCAksCFDqFd/R0+wGNaqN2fIJQ9l6IYXjKMA0GCSqGSIb3DQEBCwUAMG4x CzAJBgNVBAYTAktSMQ4wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJU2VvY2hvLWd1 MQ0wCwYDVQQKDARPU0NJMRgwFgYDVQQLDA9DbG91ZCBNaWdyYXRpb24xEjAQBgNV BAMMCWRoa2ltLmNvbTAeFw0yMjA0MjYwNjQ2NDNaFw0yMzA0MjYwNjQ2NDNaMG4x CzAJBgNVBAYTAktSMQ4wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJU2VvY2hvLWd1 MQ0wCwYDVQQKDARPU0NJMRgwFgYDVQQLDA9DbG91ZCBNaWdyYXRpb24xEjAQBgNV BAMMCWRoa2ltLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDN judmmqf88NP6KSWMkdrZzPUZpY6I2vqtzHDf0pxBvEcHyhwA76LYl5xfPL76USef xgM7etNaRJ5sre3Rr1V3AaH2VWl9ERq2EPcMY1YSvodHmyPYIQxzRIF08sofoCdY kQjpMcIkuGXdRuL8K7stlArpaYo0Urvkt0JOZSJGuxm2u7F+RrnXGpsC2s2U/A7X DG43chRy93okuSXtL/9WlQjMiPxE4vuK7EUXGCD862vAmfN+sxiZfZLUBji3g88z AY4He0PYnEakqdPtcTLXRi1K2i7KjIf5YOLKjOXXUHYAcRUGUe7J9FgW4Waq+L5j HCHI3VULUoOqTwN18zECAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAoWVuIY3jCcWg fGAT2quhcL570d/VFKusOOriuUdijN1fQGgud8I1zs/KddIDhRtFAozXJJMmBJAa Z7PytRifOMbe4DkJtHFOJOHJdrA5OVDIAgrFhDy44rZvUBMRvbAfw1aDhJKkp7Ie Anibtz+WFc3W9ys8BJ9T1utFnaU2k0V1Bj2d39fx114POpkAxOqY1PSZJVavuxPB EM4FYb5DSeglYGZJUkUadC768YVpIZH0Sbitdk3qM9WLPh0ur2GIn5hRzdGrBYUz kQOWdC1g/4y1wkGlaCn5TNtHdyrEfbI7Oer6uraCm24XpqhTFaYS0SJ9iz4zSC8X 5CU9g6AP9g== —–END CERTIFICATE—– subject=C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com issuer=C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com — No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits — SSL handshake has read 1548 bytes and written 400 bytes Verification: OK — New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AB8B353A394D3FB1E6F0945DBA7939C5DBC2B0047FE43DDB607A7AE9F232900 Session-ID-ctx: Master-Key: 37CE046D9DC270224D50D6644E1838F1CC44346B16AF5C6073C9F546DC753AB30BC06E20C13757B2676B31A28FBBCEEC PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 – 03 e5 eb fb 09 37 45 c8-9d 42 c5 8d a0 9c da 04 …..7E..B…… 0010 – 53 fa b5 8e bb d0 d2 2f-d2 90 11 b9 67 28 af 51 S……/….g(.Q 0020 – f8 92 b3 25 af 3b 43 98-78 42 af 89 1e 6c b7 d8 …%.;C.xB…l.. 0030 – ee bc d2 c5 cd 60 e3 ef-3c 8b 96 a2 83 57 2d f0 …..`..<....W-. 0040 - 72 6a aa 03 9b ac ca bc-bf cc b8 2f ba d6 31 e9 rj........./..1. 0050 - 74 37 90 d0 84 6c f8 2e-0d 20 46 1a 0c df ab a9 t7...l... F..... 0060 - e0 be 5c 9a 44 e0 66 6a-60 b1 8d 82 55 2e 38 c7 ..\.D.fj`...U.8. 0070 - 5c 7c 66 54 47 0d fe f2-54 18 4e 78 90 aa ac 11 \|fTG...T.Nx.... 0080 - 82 5c 00 42 46 10 88 23-4d f4 ce 6e db 1b 81 d2 .\.BF..#M..n.... 0090 - 45 45 95 18 35 f9 80 80-25 2d 43 4b b8 81 5c 8a EE..5...%-CK..\. 00a0 - 45 2d 16 32 84 f1 47 92-c0 46 c4 6a d2 3e f7 ad E-.2..G..F.j.>.. 00b0 – d2 64 17 a4 2b 62 7d cf-e2 29 bd 98 7e 21 9f ca .d..+b}..)..~!.. 00c0 – 42 c6 a7 3f 57 c4 b4 92-9a a0 d6 1f 21 3a 8d 15 B..?W…….!:.. Start Time: 1651027020 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes —

인증서를 Server측 handshake 에 사용되도록 지정하여,

78 Line Verification: OK 정상적으로 키 교환(exchange)이 완료된 것을 알 수 있습니다.

(3) 사설 인증서 사용 (download ssl)

앞서 진행한것 처럼, openssl 으로 원격지의 SSL 인증서를 내려 받습니다.

$ openssl s_client -servername dhkim.com -connect 192.168.56.2:443 > ${CERT}/download_dhkim.com.crt

받은 인증서로 SSL 연결을 수행해봅니다.

$ openssl s_client -servername dhkim.com -connect 192.168.56.2:443 -CAfile ${CERT}/download_dhkim.com.crt CONNECTED(00000003) depth=0 C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com verify return:1 — Certificate chain 0 s:C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com i:C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com — Server certificate —–BEGIN CERTIFICATE—– MIIDYzCCAksCFDfIh7j8xqsFYz9suq3XIC9rAG6PMA0GCSqGSIb3DQEBCwUAMG4x CzAJBgNVBAYTAktSMQ4wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJU2VvY2hvLWd1 MQ0wCwYDVQQKDARPU0NJMRgwFgYDVQQLDA9DbG91ZCBNaWdyYXRpb24xEjAQBgNV BAMMCWRoa2ltLmNvbTAeFw0yMjA1MTAwOTQ4NDdaFw0yMzA1MTAwOTQ4NDdaMG4x CzAJBgNVBAYTAktSMQ4wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJU2VvY2hvLWd1 MQ0wCwYDVQQKDARPU0NJMRgwFgYDVQQLDA9DbG91ZCBNaWdyYXRpb24xEjAQBgNV BAMMCWRoa2ltLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYY RPC8/lh6TPsWmhqgtpb5GUAfODUahfkkklR0pUafCPpVyfAoBKzMcYgEU8kK0ETf T8jF9LrforRAa6rrm7e2I3N93TzUgypRAdJeoFC1Eg1YpchHGHkoDVrMqMZdCjVZ +2QR0E8B16RedzCY55ctb0dCHckoD4nnzwvm6HInpFK6DrZBxdbEh1Dr8hiEsWtH bYeHGFWc/ugmAlVzuQLNevInKS9pUFglb7yxYpkVI4wf6C/Hyf0Wba34yBcGLtbr cF32TJrp12wAq1D16jUX1fDwiiq6P9mo0Xxw2bza17PyzeV++i2DszRjhgh9A1RE 6A/ZX15gtgYY4Bsp4e8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAgwp7vJb24g6r 78VPi3UwEkgSRbSnc9yK2KlObc2xtwK5TbibeIPdbkw5vPj9tieCgNyvKfpWnIni /CvDILdaRnAMcCbP2O3cNBK/xQDvL1pw3GMzWaZvPgqGNNQ1GOD5FzPnBXniOG8T OsY54KG31zLp7/JslJ7CmtfFFXRRMMYIRXBMJdNNZE4n4j6+SNOdhFlxAqGevrzE qKAndFkRsr//le62ddeegVZdiZiEZfbPNx3ebfs98VXV7HyvsDt3H/oRGXsBF1gl DyqobfbdovazynOi/NHZN2JJEaZREVM7itozp26cIfmgEXwWkGEocPZOGMAQYDo2 5fq8KSWaKg== —–END CERTIFICATE—– subject=C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com issuer=C = KR, ST = Seoul, L = Seocho-gu, O = OSCI, OU = Cloud Migration, CN = dhkim.com — No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits — SSL handshake has read 1431 bytes and written 387 bytes Verification: OK — New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) — — Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: A03B5C0C44A33E76139812885A5DA3FB2D93D30DAEB1FDD43573D441623E0D9E Session-ID-ctx: Resumption PSK: B6B80C4EAC340F04EE6DC74A4A24734B991646EFF0800527D5F2FDCA6EB0162F37B9864B22A1256497B024E97882B7B6 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 – 1f be 43 bb 42 73 6a cf-2a cb cc 05 fc 02 6d aa ..C.Bsj.*…..m. 0010 – c2 55 52 b8 15 1e a9 f7-bf bb 83 3d 92 9e 8d 9c .UR……..=…. 0020 – 04 74 0c 58 11 17 42 94-1b 1f 46 78 85 64 f2 69 .t.X..B…Fx.d.i 0030 – 90 8c 77 3d e0 f0 0a 28-1e aa 82 2a 66 26 07 3a ..w=…(…*f&.: 0040 – 2d b1 4b 69 5e a2 32 e0-2e 4e 6c fe 3e f0 55 64 -.Ki^.2..Nl.>.Ud 0050 – 1f 12 e8 df 93 75 2e 3b-5f 53 b2 d4 0b ce 7b c0 …..u.;_S….{. 0060 – 28 a6 1a 93 a7 b8 73 44-2f 04 6a f1 38 ab a9 0e (…..sD/.j.8… 0070 – e0 a3 ef 16 1a a1 07 f4-6f e1 37 ca 8f d2 9d a8 ……..o.7….. 0080 – 11 31 0a 4c 8b 68 38 f1-7a 76 94 14 ba ed cb 1d .1.L.h8.zv…… 0090 – a2 9e bc 2e ac 2a 6b f9-e1 67 f3 9a 78 c3 6f 89 …..*k..g..x.o. 00a0 – 18 6a f6 ed 48 92 28 06-36 ec 31 e5 f6 ed e9 45 .j..H.(.6.1….E 00b0 – a5 9b 81 f6 10 3a 11 77-00 e9 0c 02 51 e8 e7 39 …..:.w….Q..9 00c0 – 4b b7 07 0c 67 ad 06 e8-90 ff 4d 39 d2 20 23 43 K…g…..M9. #C 00d0 – c2 c6 f9 a0 44 66 f6 08-66 13 69 6c 8b ab 38 d8 ….Df..f.il..8. 00e0 – a6 a2 76 b2 2d 3b 7e 11-8a b8 fe 86 6c 8d 9a d7 ..v.-;~…..l… Start Time: 1652243552 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 — read R BLOCK — Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: CEA4F8BF660A26FDA72552816D2D050AE8252ADC5D2D9E2771811AE98AB70FEF Session-ID-ctx: Resumption PSK: D0E73731976C0FF9F7A1A2FD6AAFB03470E1F9D75E4D5B263105448ABD589D1DCA7E71C64F7FC2CB2C510FF5D6136EB9 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 – 1f be 43 bb 42 73 6a cf-2a cb cc 05 fc 02 6d aa ..C.Bsj.*…..m. 0010 – 0a d4 b9 4d 53 d8 ab 95-34 49 ae 07 72 ae 7e 8f …MS…4I..r.~. 0020 – 2b c7 a9 db 65 61 58 23-78 27 3a 61 92 97 82 49 +…eaX#x’:a…I 0030 – d8 f2 0d b8 34 b8 62 07-a7 53 1c 2c 66 2b bb 91 ….4.b..S.,f+.. 0040 – ad e2 21 dd 3d f6 69 cf-68 f2 2f c0 2f a5 c4 f8 ..!.=.i.h././… 0050 – ab fe 26 7c 4c 3d 78 31-6f 24 dd 11 7e 45 85 cc ..&|L=x1o$..~E.. 0060 – 2b 95 f5 21 8f 9c 04 b0-93 6b ba b1 e5 a5 ea 12 +..!…..k…… 0070 – 1d a5 37 d6 eb b0 d1 76-61 c2 34 6d 28 06 41 99 ..7….va.4m(.A. 0080 – 92 e7 ad 59 ab a3 22 1d-9d 6a a9 f3 fa 92 da 32 …Y..”..j…..2 0090 – 4a 49 4a 11 87 0c a9 00-a3 83 74 2a 53 d4 46 36 JIJ…….t*S.F6 00a0 – 95 45 5c e9 18 1c 45 c3-83 bf 65 5a e5 45 07 08 .E\…E…eZ.E.. 00b0 – e9 00 3f 49 ed 22 cf d2-78 46 6b a2 e7 fd d4 9e ..?I.”..xFk….. 00c0 – 63 09 ce f1 05 f8 48 90-07 7e 41 c7 4b 80 cb 48 c…..H..~A.K..H 00d0 – ab ed 29 35 c7 25 b1 09-80 b1 9e 6c 36 25 15 5d ..)5.%…..l6%.] 00e0 – 01 24 ee 24 00 62 10 e7-9b dd 22 3d 54 f0 01 19 .$.$.b….”=T… Start Time: 1652243552 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 — read R BLOCK HTTP/1.1 400 Bad Request Date: Wed, 11 May 2022 04:32:34 GMT Server: Apache Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1

Bad Request

Your browser sent a request that this server could not understand.

closed

원격지의 인증서로, SSL handshake를 시도하였고, 85 Line 로그를 통해 정상적으로 처리된 것을 알 수 있습니다.

4.3 HttpUrlConnection (JAVA)

여기서는 JAVA 기반의 어플리케이션을 통해 원격지 서버와 SSL 통신을 수립해봅니다.

테스트를 위해 다음의 어플리케이션이 AP에 배포된다고 가정합니다.

<%@ page contentType="text/html; charset=UTF-8" %> <%@ page import="java.io.*" %> <%@ page import="java.net.*" %> <% URL url = new URL("https://dhkim.com/index.html".toString()); HttpURLConnection connection = (HttpURLConnection) url.openConnection(); connection.setDoOutput(true); OutputStreamWriter osw = new OutputStreamWriter(connection.getOutputStream()); try { osw.write(""); osw.flush(); } finally { if (osw != null) osw.close(); } BufferedReader brin = new BufferedReader(new InputStreamReader(connection.getInputStream())); String resStr = null; StringBuffer resStrBuff = new StringBuffer(); try { while ((resStr = brin.readLine()) != null) { resStrBuff.append(resStr); } } finally { if (brin != null) brin.close(); } out.println(resStrBuff); System.out.println(resStrBuff); %>

단순히, AP 호출 시 https://dhkim.com/index.html 을 호출하는 소스코드 입니다.

(1) AP 호출하여 HTTPS 연결

AP에 배포된 어플리케이션을 호출하면, HttpUrlConnection Class가 https://dhkim.com/index.html 을 호출합니다. 그러나, 원격지(requested target)와 SSL Handshake에 필요한 유효한 인증서가 없어(unable to find valid certi..) Exception 이 발생하였습니다.

Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

(2) SSL 인증서 to Java Key Store 변환

AP(Client; 호출자)에 SSL 인증서 Setup을 위해 JKS로 변환하는 과정이 필요합니다. JAVA 기반에서는 SSL 인증서를 JKS로 감싸주어야 이해할 수 있기 때문입니다.

$ cat ${CERT}/private.key ${CERT}/dhkim.com.crt ${CERT}/root.csr > ${CERT}/dhkim.com.pem

개인키, 서버 인증서, CSR 인증서를 하나의 dhkim.com.pem 파일로 합칩니다.

확장자를 pem 으로 만들었다고, 완성되는 것이 아닙니다. pkcs12 Format으로 변환 해주어야 합니다.

$ openssl pkcs12 -export -in ${CERT}/dhkim.com.pem -out ${CERT}/dhkim.com.p12 Enter pass phrase for /tmp/self_signed_cert/dhkim.com.pem: (dhkim) Enter Export Password: (pkcs123456) Verifying – Enter Export Password: (pkcs123456)

private.key 암호인 dhkim 와 p12 파일의 암호인 pkcs123456 을 차례대로 입력합니다.

pkcs12 Format은 하나의 단일 File에 여러개의 인증서를 묶을 수 있게 해줍니다.

pkcs12 Format 파일을 JKS에 집어 넣습니다.

$ keytool -importkeystore -srcstoretype pkcs12 -srckeystore ${CERT}/dhkim.com.p12 -deststoretype jks -destkeystore ${CERT}/dhkim.com.jks 키 저장소 /tmp/self_signed_cert/dhkim.com.p12을(를) /tmp/self_signed_cert/dhkim.com.jks(으)로 임포트하는 중… 대상 키 저장소 비밀번호 입력: (jks123456) 새 비밀번호 다시 입력: (jks123456) 소스 키 저장소 비밀번호 입력: (pkcs123456) 1 별칭에 대한 항목이 성공적으로 임포트되었습니다. 임포트 명령 완료: 성공적으로 임포트된 항목은 1개, 실패하거나 취소된 항목은 0개입니다. Warning: JKS 키 저장소는 고유 형식을 사용합니다. “keytool -importkeystore -srckeystore /tmp/self_signed_cert/dhkim.com.jks -destkeystore /tmp/self_signed_cert/dhkim.com.jks -deststoretype pkcs12″를 사용하는 산업 표준 형식인 PKCS12로 이전하는 것이 좋습니다.

dhkim.com.jks 암호인 jks123456 와 dhkim.com.p12 암호인 pkcs123456 을 차례대로 입력합니다.

(3) JKS Setup 후 HTTPS 재연결

위에서 생성한 JKS를 AP에 Setup 합니다.

CERT=/tmp/self_signed_cert export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.keyStoreType=JKS” export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.keyStore=${CERT}/dhkim.com.jks” export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.keyStorePassword=jks123456″ export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.trustStore=${CERT}/dhkim.com.jks” export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.trustStorePassword=jks123456″ export JAVA_OPTS

AP에서 HttpUrlConnection을 통해 HTTPS WEB을 호출하면 에러가 여전히 발생하고 있습니다. 아까와는 다른 에러 로그가 보입니다. Cannot recover key 는 대게, SSL 인증서를 제공된 패스워드로 해독할 수 없어 발생합니다.

는 대게, SSL 인증서를 제공된 패스워드로 해독할 수 없어 발생합니다. 위에서 JKS, PKCS12 각기 다른 패스워드로 관리하기 위해 지정하였는데 에러가 발생했습니다. 이 부분에서는 도움이 될 만한 힌트 등을 구글링으로 알 수가 없었습니다.

java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) … java.security.UnrecoverableKeyException: Cannot recover key

Cannot recover key 는, dhkim.com.jks Keystore 에 추가한 개인키 인증서를 jks123456 값으로 해독할 수 없어 발생합니다.

Keystore Password를 변경합니다.

$ keytool -storepasswd -keystore ${CERT}/dhkim.com.jks 키 저장소 비밀번호 입력: (jks123456) 새 keystore password: (dhkim123456) 새 keystore password 다시 입력: (dhkim123456) Warning: JKS 키 저장소는 고유 형식을 사용합니다. “keytool -importkeystore -srckeystore /tmp/self_signed_cert/dhkim.com.jks -destkeystore /tmp/self_signed_cert/dhkim.com.jks -deststoretype pkcs12″를 사용하는 산업 표준 형식인 PKCS12로 이전하는 것이 좋습니다.

생성한 keystore의 password를 dhkim123456 으로 변경했습니다.

Keystore 내에 저장된 인증서 Password를 변경합니다. dhkim.com.jks Keystore Password와 Keystore 내에 저장된 인증서의 Password를 동일하게 변경하는 작업입니다.

$ keytool -keypasswd -keystore ${CERT}/dhkim.com.jks -alias 1 키 저장소 비밀번호 입력: (dhkim123456) <1>에 대한 키 비밀번호를 입력하십시오. (pkcs123456) 새 <1>에 대한 키 비밀번호: (dhkim123456) 새 <1>에 대한 키 비밀번호 다시 입력: (dhkim123456) Warning: JKS 키 저장소는 고유 형식을 사용합니다. “keytool -importkeystore -srckeystore /tmp/self_signed_cert/dhkim.com.jks -destkeystore /tmp/self_signed_cert/dhkim.com.jks -deststoretype pkcs12″를 사용하는 산업 표준 형식인 PKCS12로 이전하는 것이 좋습니다.

-alias 1 : 처음에 Keystore 내에 인증서( dhkim.com.p12 )를 저장할 때, 별칭을 주지 않았으므로 기본값 1이 지정되었습니다.

다음과 같이 AP Setup 한 내용 중에, Password 를 변경합니다.

CERT=/tmp/self_signed_cert export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.keyStoreType=JKS” export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.keyStore=${CERT}/dhkim.com.jks” export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.keyStorePassword=dhkim123456″ export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.trustStore=${CERT}/dhkim.com.jks” export JAVA_OPTS=”$JAVA_OPTS -Djavax.net.ssl.trustStorePassword=dhkim123456″ export JAVA_OPTS

AP → HTTPS WEB 호출 시, STDOUT Log 또는, 웹 브라우저에 문제가 없고 결과물이 잘 나오는 것을 확인하였습니다.

Hello world
/tmp/htdocs_ssl/index.html

5. 마무리

SSL 인증서를 여러 환경에 적용해보고, curl 과 openssl 명령으로 검증을 수행해보았습니다.

이 테스트를 하게 된 계기는, 고객사의 SSL 인증서 교체 이후 검증 방식을 제대로 알고 있지 않아 준비해보게 되었습니다.

물론, 고객사의 이슈와는 전혀 다른 상황이 펼쳐지더라도. 때때로 SSL 인증 과정에 문제가 없는지 확인할 필요성이 많기 때문에 저에게는 유용한 시간이 되었습니다.

이것으로 글을 마무리 하며, 다음 시간에는 Spring Security의 Session Fixation 을 이슈로 겪었던 사례를 가지고 찾아뵙도록 하겠습니다.

사설인증서 분석

오늘부터 전면 폐지되는 공인인증서(사실은 공동인증서로 이름만 바뀌고 다른 사업자가 뛰어들 수 있게 개방형으로 바뀌는 거지만)

그러다보니 사설인증서들이 너도나도 뛰어드는 모습인데 정리를 위해 메모. 나중에 생각이 정제되면 글은 업데이트 혜정입니다.

요약정보

유효기간 2년

발급시 카카오페이 앱/카카오톡, 사용 시 카카오톡 앱 호출

인증비밀번호 있음

발급절차: 휴대폰본인인증-계좌인증

사용처: 금융상품 가입, 간편로그인

유효기간 3년

네이버앱

인증서 비밀번호 설정 없음(단말 인증)

발급절차: 휴대폰본인인증

사용처: 지방세 고지확인, 출금동의 등

유효기간 3년

PASS앱

인증서 비밀번호 설정 없음(앱인증비번)

발급절차: 없음(앱 설치 후 약관동의)

사용처: 상품가입(웹) 등

유효기간 2년

페이코앱

인증비밀번호 설정 없음 (단말인증)

발급절차: 휴대폰본인인증(iOS 기기인증)

사용처: 출금동의 등 주로 내부 서비스

유효기간 2년

TOSS앱

인증서 비밀번호 설정 없음(단말인증)

발급절차: 없음

사용처: 상품가입(웹) 등

평생(1년 미이용 및 단말 변경시 재발급 필요)

KB스타 앱

인증서 비밀번호 있음(간편비번, 생체인증 가능)

발급절차: 휴대폰본인인증- 기기인증

사용처: KB금융그룹 인증

유효기간 3년

IBK 앱

인증서 비밀번호 설정 없음(앱인증비번)

발급절차: 없음

사용처: 상품가입(웹) 등

0.진입점

카카오페이 메뉴 내 제공, 하지만 주로 사용처에서 호출하면 카카오톡 내 모듈을 호출해온다.

네이버의 다양한 진입점

메인 카드와 하단 네비게이션 탭의 첫번째로 확실히 밀어주는 패스

전체 메뉴로 접근하도록 제공하는 페이코와 토스

일반은행은 인증센터 내 제공

1. 발급절차

카카오페이

비교적 일찍 시작, 인증서 비밀번호를 설정해야 하는 등 타사보다 단계가 많다.

네이버인증서

약관&휴대폰 본인인증동의 후 기기 바이오 인증으로 심플하게 끝남

cf. 안드로이드는 이용약관과 본인확인 절차 분리

패스(PASS)

대부분의 인증은 앱설치 단계에서 이미 받기 때문에 인증서 발급은 매우 간편한 편. 너무 간편해서 안전한지 불안할 정도다.

토스(TOSS)

페스와 마찬가지로 매우 간편하게 발급되어 신뢰성이 오히려 저하됨

페이코(PAYCO)

KB

다른 인증수단 선택시 모바일인증서 설치 유도 팝업을 제공하는 등 힘을 받고 있는 모습

IBK

앱설치 및 인증과정에 자연스럽게 발급받도록 프로세스를 녹였다.

2. 사용방법

카카오페이

간편로그인 기능 주로 제공

간편로그인 사용

네이버인증서

주로 내부 금융 서비스의 계좌연결이나 서울시 주민세 납부 등 사용, 네이버 페이와 연계 등 자사 서비스 시너지 발생

사용이력 확인

계좌 연결

주민세 납부

패스

금융서비스 가입시 사용

[서비스 이용가능 제휴사]

– 동양생명보험 : 인터넷 홈페이지, 모바일홈페이지, 모바일스마트창구

– KT비즈메카 : 공공문자알림

– 미래에셋대우 : 인터넷홈페이지, 모바일웹 페이지 전자투표

– NEIS학부모인증서 : 인증서 발급 시 본인확인용

– 핀크(Finnq) : 핀크앱 출금이체동의

– 세틀뱅크 : 내통장결제 출금이체동의

– IBK연금보험 : 인터넷 사이버창구, 모바일 사이버창구, 모바일앱 내 로그인, 간편인증, 전자계약

– KB손해보험 : 인터넷, 모바일 다이렉트

[오픈 예정 제휴사]

– 금융권 : NH농협은행 올원뱅크, 흥국생명보험, ABL생명보험, 우리캐피탈

– 공공기관 : 한국디지털저작권거래소

– 통신/에너지 : SK텔링크, SK E&S

– 핀테크 : VP, 다방, KS-Net, AIM, 엠마우스

토스

금융사 상품가입 시 인증에 사용

페이코

출금계좌 등록 등 아직 내부서비스에 국한

KB

KB금융그룹 서비스 전반에 사용이용 채널

KB국민은행: KB스타뱅킹, 인터넷뱅킹(PC), KB마이머니, 리브(Liiv), 리브똑똑

KB금융그룹: KB손해보험(대표앱, 다이렉트), KB저축은행(kiwibank), KB생명보험, KB증권, KB국민카드

이체 한도

– 개인별 설정한 인터넷뱅킹 이체한도 이내

※ 최대 1회 1억원, 1일 5억원

IBK

은행 앱 거래 전반에 사용

3. 관리/재발급/삭제

카카오페이

만기 예정시 연장하기 버튼이 계속 따라다님

삭제는 버튼 터치 시 컨펌팝업 제공 및 삭제 후 카카오톡 알림 제공

네이버인증서

버튼으로 손쉽게 삭제, 재발급 시 신규발급 절차와 동일

패스

버튼으로 손쉽게 삭제 또는 재발급, 삭제 시에는 컨펌 팝업도 제공하지 않음. 인증 내역 외 발급내역 확인기능 제공 안함

토스

삭제 미제공

페이코

KB

별도 관리 삭제 재발급 없이 평생 사용. 단 1년 이상 미사용 혹은 기기변경 시 신규 발급 프로세스 동일하게 진행

IBK

앱 내 메뉴로 제공

한국정보인증, 사설인증서 인증시스템 구축 시장 본격 진출

한국정보인증이 사설인증서 인증시스템 구축 시장에 본격 진출한다.

국내 최초로 공동인증서, 사설인증서(S-PASS인증서비스) 전자서명인증사업자 인정을 모두 획득한 기술력과 컨설팅 노하우를 앞세운다.

한국정보인증은 사설인증시스템 구축 및 전자서명인증사업자를 취득하려는 고객에 시스템 구축 지원과 평가 대응 컨설팅을 제공한다고 6일 밝혔다.

앞서 한국정보인증은 사설인증서 인증시스템 구축 시장에서 주요 사업을 수주했다. 지난해 8월 SK텔레콤의 PASS인증서 시스템 구축 및 전자서명인증사업자 자격 취득 사업(제 2021-014호, SK텔레콤 PASS인증서 서비스)에 최적화된 CA 인증서 발급 시스템을 납품함으로써 안정성을 입증했다.

지난해 12월에는 우리은행의 사설인증시스템 구축 및 전자서명인증사업자 자격 취득을 위한 프로젝트를 수주, 시장에서 두각을 나타냈다.

한국정보인증은 레퍼런스를 기반으로 금융뿐만 아니라 다양한 분야에서 사설인증서 인증시스템 구축 전문 기업으로 시장을 선도한다는 목표다. 인증시스템을 자체 구축·운영하고 공인인증서비스를 제공했던 노하우를 활용해 고객에 최상 서비스를 제공한다는 복안이다.

한국정보인증은 국내 최초로 공동인증서와 S-PASS인증서비스 전자서명인증사업자 인정을 모두 획득했다. 전자서명인증사업자 평가는 전자서명법 개정 이후 전자서명인증 서비스 안정성과 신뢰성을 위해 도입된 제도다. 평가기관의 평가와 과학기술정보통신부 및 한국인터넷진흥원(KISA) 인정을 거쳐 자격이 부여된다.

한국정보인증은 사설인증서 인증시스템 구축 사업을 통해 고성장 구조를 확보할 것으로 기대하고 있다. 영업이익 기준 매년 평균 8% 이상 성장중인 기존 공동인증서 사업과 올해 본격화되는 사설인증서 시스템 구축 및 전자서명인증사업자 컨설팅 사업의 시너지를 통해 영업이익 200억원을 달성한다는 목표다.

높은 성장이 기대되는 메타버스 분야에서도 보안 인증 사업을 추진, 통합 보안 인증 기업으로 지위를 확고히 다진다는 청사진을 그리고 있다.

한국정보인증 관계자는 “전자서명인증사업자 인정을 받았고 검증된 기술력과 전문 인력, 심사 대응 노하우까지 모두 갖춘 게 한국정보인증만의 차별점”이라며 “사설인증시스템 구축 및 전자서명인증사업자를 취득하려는 고객에 전방위적 사업 노하우를제공할 수 있는 유일한 기업”이라고 말했다.

최호기자 [email protected]

자체 서명 사설 SSL 인증서 만들기

사설 인증서를 만들고 웹 서버 설정 후 브라우저에서 사용하기까지 전체 과정을 살펴보고, 실습을 통해 쉽게 적용하고 사용할 수 있습니다.

사설 인증서를 만들고 웹 서버 설정 후 브라우저에서 사용하기까지 전체 과정을 살펴보고, 실습을 통해 쉽게 적용하고 사용할 수 있습니다.

웹 브라우저에서 https로 접속 시 서버 인증서를 발급한 CA(루트 인증 기관)를 식별한 다음 서버 인증서를 SSL 통신에 사용합니다. 잘 알려진 CA(예: GoDaddy 또는 DigiCert)에 의해 서명된 경우 기본적으로 웹 사이트의 인증서를 신뢰합니다. 이 경우 루트 인증서를 PC에 설치할 필요가 없습니다. 그러나 개발/테스트 환경이 있고 CA 서명된 인증서를 구입하지 않고 사용하려면 사용자 지정 CA를 직접 만들고 자체 서명된 인증서를 만들어서 사용할 수 있습니다.

[message]

##info-circle## 참고하기!

자체 서명된 인증서는 기본적으로 신뢰할 수 없으며, 오래된 해시 및 암호 제품군을 사용할 수도 있습니다. 외부에 공개된 웹 사이트에서 보안을 강화하려면 잘 알려진 인증 기관에서 서명한 인증서를 구입해서 사용하십시오.

이 문서에서는 다음 방법을 설명합니다.

사용자 지정 인증서 기관 만들기

사용자 지정 CA에서 서명한 자체 서명 인증서 만들기

웹 서버에 SSL 인증서 적용하기

자체 서명된 루트 인증서를 개인 컴퓨터에 설치해서 웹 서버 인증하기

사전 요구 사항

OpenSSL이 설치 된 윈도우나 리눅스

인증서 관리에 사용할 수 있는 다른 도구가 있을 수 있지만 이 문서에서는 OpenSSL을 사용합니다. 오픈 소스인 OpenSSL은 가장 인기 있는 도구 중 하나입니다. 모든 주요 플랫폼에서 사용할 수 있으며, 키 생성을 위한 간단한 명령줄 인터페이스를 제공합니다. 웹 서버 NGINX 웹 서버를 사용하여 인증서를 테스트합니다.

실습 환경

운영 체제(OS) : CentOS 8

권한이 있는 root 및 사용자 계정으로 실행

실행 경로 : /root/ssl

IP 설정 및 인터넷이 가능한 환경

OpenSSL 설치 확인하기

openssl version 명령어로 확인하기

CentOS 8에서는 기본 번들로 OpenSSL이 설치되어 있습니다.

[openssl version] [root@runit ssl]# openssl version OpenSSL 1.1.1c FIPS 28 May 2019

루트 인증서(CA) 만들기

OpenSSL을 사용하여 루트 인증서(CA)를 만듭니다.

루트 인증서 키 만들기

OpenSSL이 설치된 서버에 SSH 로그인 후 다음 명령을 실행합니다. 이렇게 하면 암호로 보호된 키가 만들어집니다.

rootca.key 파일 만들기

[openssl ecparam -out rootca.key -name prime256v1 -genkey]

rootca.key 파일 내용 확인하기

[cat rootca.key] [root@runit ssl]# cat rootca.key —–BEGIN EC PARAMETERS—– BggqhkjOPQMBBw== —–END EC PARAMETERS—– —–BEGIN EC PRIVATE KEY—– MHcCAQEEIIHjF6gSS4xlCP097jjjVkl7w+GjrL/SuvHqYx+su9cboAoGCCqGSM49 AwEHoUQDQgAEquz+t68EzC+xVpjdqH+1k5D7xDjIboRzXi/m/dDsGWceXlwlw385 JHWQujPEqE4tIjY/UoS94DtNUjaoeABxFw== —–END EC PRIVATE KEY—–

루트 인증서 CSR(인증 서명 요청) 만들기

다음 명령을 사용하여 인증서 발급에 필요한 정보를 담고 있는 인증서 서명 요청 파일(csr)을 생성합니다.

rootca.csr 인증 서명 요청 파일 만들기

입력 프롬프트가 표시되면 정규화된 도메인 이름(발급자의 도메인)과 같은 사용자 지정 CA에 대한 조직 정보를 입력합니다.

[openssl req -new -sha256 -key rootca.key -out rootca.csr] [root@runit ssl]# openssl req -new -sha256 -key rootca.key -out rootca.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —– Country Name (2 letter code) [XX]: KR State or Province Name (full name) []: Gyeonggi-do Locality Name (eg, city) [Default City]: Hwaseong Organization Name (eg, company) [Default Company Ltd]: RunIT Organizational Unit Name (eg, section) []: Cloud Common Name (eg, your name or your server’s hostname) []: RunIT.Cloud CA Root Certificate Email Address []: [email protected] Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: Enter 누르기 An optional company name []: Enter 누르기

rootca.csr 인증 서명 요청 파일 내용 확인하기

암호화된 인증 서명 요청 파일( csr)을 확인할 수 있습니다.

[cat rootca.csr] [root@runit ssl]# cat rootca.csr —–BEGIN CERTIFICATE REQUEST—– MIIBYjCCAQkCAQAwgaYxCzAJBgNVBAYTAktSMRQwEgYDVQQIDAtHeWVvbmdnaS1k bzERMA8GA1UEBwwISHdhc2VvbmcxDjAMBgNVBAoMBVJ1bklUMQ4wDAYDVQQLDAVD bG91ZDEoMCYGA1UEAwwfUnVuSVQuQ2xvdWQgQ0EgUm9vdCBDZXJ0aWZpY2F0ZTEk MCIGCSqGSIb3DQEJARYVd2VibWFzdGVyQHJ1bml0LmNsb3VkMFkwEwYHKoZIzj0C AQYIKoZIzj0DAQcDQgAEquz+t68EzC+xVpjdqH+1k5D7xDjIboRzXi/m/dDsGWce Xlwlw385JHWQujPEqE4tIjY/UoS94DtNUjaoeABxF6AAMAoGCCqGSM49BAMCA0cA MEQCIHEXV+MEF5mJ91HQsr6mtMWzvvIHYAPGPtBlUWsnsq3BAiBOGOQ5skrTdiIM +ACVgnECu/ZqM6BPaBvZJS9WUZACVQ== —–END CERTIFICATE REQUEST—–

루트 인증서(CA)를 만들고 자체 서명하기

다음 명령을 사용하여 인증서 발급에 필요한 정보를 담고 있는 인증서 서명 요청 파일(csr) 및 인증서(CA)를 생성합니다.

rootca.crt SSL 인증서 파일 만들기

인증 기간은 최대 6자리로 설정할 수 있습니다.

일반적으로 365일(1년)로 생성하거나 3650일(10년)로 생성할 수 있습니다.

이 문서에서는 최대 기간인 999999일(2739)년으로 인증서를 생성합니다.

[openssl x509 -req -sha256 -days 999999 -in rootca.csr -signkey rootca.key -out rootca.crt] [root@runit ssl]# openssl x509 -req -sha256 -days 999999 -in rootca.csr -signkey rootca.key -out rootca.crt Signature ok subject=C = KR, ST = Gyeonggi-do, L = Hwaseong, O = RunIT, OU = Cloud, CN = RunIT.Cloud CA Root Certificate, emailAddress = [email protected] Getting Private key

rootca.crt SSL 인증서 파일 내용 확인하기

암호화된 SSL 인증서(crt)를 확인할 수 있습니다.

[cat rootca.crt] [root@runit ssl]# cat rootca.crt —–BEGIN CERTIFICATE—– MIICTDCCAfECFEr5tNn4vOOrq6TZlercP9zj9ND6MAoGCCqGSM49BAMCMIGmMQsw CQYDVQQGEwJLUjEUMBIGA1UECAwLR3llb25nZ2ktZG8xETAPBgNVBAcMCEh3YXNl b25nMQ4wDAYDVQQKDAVSdW5JVDEOMAwGA1UECwwFQ2xvdWQxKDAmBgNVBAMMH1J1 bklULkNsb3VkIENBIFJvb3QgQ2VydGlmaWNhdGUxJDAiBgkqhkiG9w0BCQEWFXdl Ym1hc3RlckBydW5pdC5jbG91ZDAgFw0yMDA0MTMwNzQxMzZaGA80NzU4MDMxMDA3 NDEzNlowgaYxCzAJBgNVBAYTAktSMRQwEgYDVQQIDAtHeWVvbmdnaS1kbzERMA8G A1UEBwwISHdhc2VvbmcxDjAMBgNVBAoMBVJ1bklUMQ4wDAYDVQQLDAVDbG91ZDEo MCYGA1UEAwwfUnVuSVQuQ2xvdWQgQ0EgUm9vdCBDZXJ0aWZpY2F0ZTEkMCIGCSqG SIb3DQEJARYVd2VibWFzdGVyQHJ1bml0LmNsb3VkMFkwEwYHKoZIzj0CAQYIKoZI zj0DAQcDQgAEquz+t68EzC+xVpjdqH+1k5D7xDjIboRzXi/m/dDsGWceXlwlw385 JHWQujPEqE4tIjY/UoS94DtNUjaoeABxFzAKBggqhkjOPQQDAgNJADBGAiEA8syO fe6lOTE28ntDB1mUsJAheBEWqxc87+YZNj05Gn0CIQCKDZTwr3W91eRERx/B3+hh JY7KdQNx3ZqiutJu/L4JRQ== —–END CERTIFICATE—–

서버 인증서 만들기

서버 인증서 키 만들기

OpenSSL을 사용하여 서버 인증서를 만듭니다.

server.key 파일 만들기

다음 명령을 사용하여 서버 인증서에 대한 키를 생성합니다.

[openssl ecparam -out server.key -name prime256v1 -genkey]

server.key 파일 내용 확인하기

암호화된 키 파일이 생성된 것을 확인할 수 있습니다.

[cat server.key] [root@runit ssl]# cat server.key —–BEGIN EC PARAMETERS—– BggqhkjOPQMBBw== —–END EC PARAMETERS—– —–BEGIN EC PRIVATE KEY—– MHcCAQEEIDngU19/T0y/tf3hs/Dtf9vU884/vSzXhgRKa8K0vy6boAoGCCqGSM49 AwEHoUQDQgAEuCVmi+HEIZID2uOMzkr7hhuIxCUuQE7o9sC69zHzcWdJrpP0VvA2 nPe+LLlz9lX6998BUDWR7+KFrbVKzXrvFg== —–END EC PRIVATE KEY—–

서버 인증서 CSR(인증 서명 요청) 만들기

다음 명령을 사용하여 인증서 발급에 필요한 정보를 담고 있는 인증서 서명 요청 파일(csr)을 생성합니다.

[message]

##info-circle## 참고하기!

서버 인증서의 CN(일반 이름)은 발급자의 도메인과 달라야 합니다. 예를 들어 이 경우 발급자의 CN은 RunIT.Cloud CA Root Certificate 이며 서버 인증서의 CN은 *.in.runit.cloud 입니다.

server.csr 인증 서명 요청 파일 만들기

CSR은 인증서를 요청할 때 CA에 제공하는 공개 키입니다. CA는 CSR 요청에 대한 인증서를 발급합니다.

입력 프롬프트가 표시되면 정규화된 도메인 이름(발급자의 도메인)과 같은 사용자 지정 CA에 대한 조직 정보를 입력합니다.

[openssl req -new -sha256 -key server.key -out server.csr] [root@runit ssl]# openssl req -new -sha256 -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —– Country Name (2 letter code) [XX]: KR State or Province Name (full name) []: Gyeonggi-do Locality Name (eg, city) [Default City]: Hwaseong Organization Name (eg, company) [Default Company Ltd]: RunIT Organizational Unit Name (eg, section) []: Cloud Common Name (eg, your name or your server’s hostname) []: *.in.runit.cloud Email Address []: [email protected] Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: Enter 누르기 An optional company name []: Enter 누르기

server.csr 인증 서명 요청 파일 내용 확인하기

암호화된 인증 서명 요청 파일( csr)을 확인할 수 있습니다.

[cat server.csr] [root@runit ssl]# cat server.csr —–BEGIN CERTIFICATE REQUEST—– MIIBUzCB+gIBADCBlzELMAkGA1UEBhMCS1IxFDASBgNVBAgMC0d5ZW9uZ2dpLWRv MREwDwYDVQQHDAhId2FzZW9uZzEOMAwGA1UECgwFUnVuSVQxDjAMBgNVBAsMBUNs b3VkMRkwFwYDVQQDDBAqLmluLnJ1bml0LmNsb3VkMSQwIgYJKoZIhvcNAQkBFhV3 ZWJtYXN0ZXJAcnVuaXQuY2xvdWQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAS4 JWaL4cQhkgPa44zOSvuGG4jEJS5ATuj2wLr3MfNxZ0muk/RW8Dac974suXP2Vfr3 3wFQNZHv4oWttUrNeu8WoAAwCgYIKoZIzj0EAwIDSAAwRQIhAJ/hYrruQO3DHGJl Hvd7lsUtEz535P3JfQHUU2FhVhUTAiBLaJLl3OTX/4g5ma0vf2Lj+w2x7EKu+TIk sSp5Dx5Lkg== —–END CERTIFICATE REQUEST—–

서버 인증서를 만들고 자체 서명하기

다음 명령을 사용하여 CSR 및 키로 인증서를 생성하고 CA의 루트 키로 서명합니다.

server.crt SSL 인증서 파일 만들기

인증 기간은 최대 6자리로 설정할 수 있습니다.

일반적으로 365일(1년)로 생성하거나 3650일(10년)로 생성할 수 있습니다.

이 문서에서는 최대 기간인 999999일(2739)년으로 인증서를 생성합니다.

[openssl x509 -req -sha256 -days 999999 -in server.csr -CA rootca.crt -CAkey rootca.key -CAcreateserial -out server.crt] [root@runit ssl]# openssl x509 -req -sha256 -days 999999 -in server.csr -CA rootca.crt -CAkey rootca.key -CAcreateserial -out server.crt Signature ok subject=C = KR, ST = Gyeonggi-do, L = Hwaseong, O = RunIT, OU = Cloud, CN = *.in.runit.cloud, emailAddress = [email protected] Getting CA Private Key

server.crt SSL 인증서 파일 내용 확인하기

암호화된 SSL 인증서(crt)를 확인할 수 있습니다.

[cat server.crt] [root@runit ssl]# cat server.crt —–BEGIN CERTIFICATE—– MIICOzCCAeICFG9XTpxwenVnMyJi7RblVYkys8+gMAoGCCqGSM49BAMCMIGmMQsw CQYDVQQGEwJLUjEUMBIGA1UECAwLR3llb25nZ2ktZG8xETAPBgNVBAcMCEh3YXNl b25nMQ4wDAYDVQQKDAVSdW5JVDEOMAwGA1UECwwFQ2xvdWQxKDAmBgNVBAMMH1J1 bklULkNsb3VkIENBIFJvb3QgQ2VydGlmaWNhdGUxJDAiBgkqhkiG9w0BCQEWFXdl Ym1hc3RlckBydW5pdC5jbG91ZDAgFw0yMDA0MTUwMTQ0MTNaGA80NzU4MDMxMjAx NDQxM1owgZcxCzAJBgNVBAYTAktSMRQwEgYDVQQIDAtHeWVvbmdnaS1kbzERMA8G A1UEBwwISHdhc2VvbmcxDjAMBgNVBAoMBVJ1bklUMQ4wDAYDVQQLDAVDbG91ZDEZ MBcGA1UEAwwQKi5pbi5ydW5pdC5jbG91ZDEkMCIGCSqGSIb3DQEJARYVd2VibWFz dGVyQHJ1bml0LmNsb3VkMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEuCVmi+HE IZID2uOMzkr7hhuIxCUuQE7o9sC69zHzcWdJrpP0VvA2nPe+LLlz9lX6998BUDWR 7+KFrbVKzXrvFjAKBggqhkjOPQQDAgNHADBEAiApY8yR6oW6L3RZnWtC0ZV4paM2 CxSedAUSiMLLf43OwAIgeAVI9XkMQUkXHkZ19YtviY0SQDmj2WEEUJiJ6K+q2+0= —–END CERTIFICATE—–

인증서 정보 확인하기

다음 명령을 사용하여 CRT 파일을 출력하고 해당 내용을 확인합니다.

[openssl x509 -in server.crt -text -noout] [root@runit ssl]# openssl x509 -in server.crt -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: 6f:57:4e:9c:70:7a:75:67:33:22:62:ed:16:e5:55:89:32:b3:cf:a0 Signature Algorithm: ecdsa-with-SHA256 Issuer: C = KR, ST = Gyeonggi-do, L = Hwaseong, O = RunIT, OU = Cloud, CN = RunIT.Cloud CA Root Certificate, emailAddress = [email protected] Validity Not Before: Apr 15 01:44:13 2020 GMT Not After : Mar 12 01:44:13 4758 GMT Subject: C = KR, ST = Gyeonggi-do, L = Hwaseong, O = RunIT, OU = Cloud, CN = *.in.runit.cloud, emailAddress = [email protected] Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:b8:25:66:8b:e1:c4:21:92:03:da:e3:8c:ce:4a: fb:86:1b:88:c4:25:2e:40:4e:e8:f6:c0:ba:f7:31: f3:71:67:49:ae:93:f4:56:f0:36:9c:f7:be:2c:b9: 73:f6:55:fa:f7:df:01:50:35:91:ef:e2:85:ad:b5: 4a:cd:7a:ef:16 ASN1 OID: prime256v1 NIST CURVE: P-256 Signature Algorithm: ecdsa-with-SHA256 30:44:02:20:29:63:cc:91:ea:85:ba:2f:74:59:9d:6b:42:d1: 95:78:a5:a3:36:0b:14:9e:74:05:12:88:c2:cb:7f:8d:ce:c0: 02:20:78:05:48:f5:79:0c:41:49:17:1e:46:75:f5:8b:6f:89: 8d:12:40:39:a3:d9:61:04:50:98:89:e8:af:aa:db:ed

웹 서버에 SSL 인증서 적용하기

CA 인증서를 포함하는 서버 인증서 만들기

CAT 명령을 사용해서 server.crt 와 rootca.crt 파일 내용을 합친 인증서 파일을 생성합니다.

[cat server.crt rootca.crt > server.pem]

server.pem 파일 내용 확인하기

[cat server.pem] [root@runit ssl]# cat server.pem —–BEGIN CERTIFICATE—– MIICOzCCAeICFG9XTpxwenVnMyJi7RblVYkys8+gMAoGCCqGSM49BAMCMIGmMQsw CQYDVQQGEwJLUjEUMBIGA1UECAwLR3llb25nZ2ktZG8xETAPBgNVBAcMCEh3YXNl b25nMQ4wDAYDVQQKDAVSdW5JVDEOMAwGA1UECwwFQ2xvdWQxKDAmBgNVBAMMH1J1 bklULkNsb3VkIENBIFJvb3QgQ2VydGlmaWNhdGUxJDAiBgkqhkiG9w0BCQEWFXdl Ym1hc3RlckBydW5pdC5jbG91ZDAgFw0yMDA0MTUwMTQ0MTNaGA80NzU4MDMxMjAx NDQxM1owgZcxCzAJBgNVBAYTAktSMRQwEgYDVQQIDAtHeWVvbmdnaS1kbzERMA8G A1UEBwwISHdhc2VvbmcxDjAMBgNVBAoMBVJ1bklUMQ4wDAYDVQQLDAVDbG91ZDEZ MBcGA1UEAwwQKi5pbi5ydW5pdC5jbG91ZDEkMCIGCSqGSIb3DQEJARYVd2VibWFz dGVyQHJ1bml0LmNsb3VkMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEuCVmi+HE IZID2uOMzkr7hhuIxCUuQE7o9sC69zHzcWdJrpP0VvA2nPe+LLlz9lX6998BUDWR 7+KFrbVKzXrvFjAKBggqhkjOPQQDAgNHADBEAiApY8yR6oW6L3RZnWtC0ZV4paM2 CxSedAUSiMLLf43OwAIgeAVI9XkMQUkXHkZ19YtviY0SQDmj2WEEUJiJ6K+q2+0= —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– MIICTDCCAfECFEr5tNn4vOOrq6TZlercP9zj9ND6MAoGCCqGSM49BAMCMIGmMQsw CQYDVQQGEwJLUjEUMBIGA1UECAwLR3llb25nZ2ktZG8xETAPBgNVBAcMCEh3YXNl b25nMQ4wDAYDVQQKDAVSdW5JVDEOMAwGA1UECwwFQ2xvdWQxKDAmBgNVBAMMH1J1 bklULkNsb3VkIENBIFJvb3QgQ2VydGlmaWNhdGUxJDAiBgkqhkiG9w0BCQEWFXdl Ym1hc3RlckBydW5pdC5jbG91ZDAgFw0yMDA0MTMwNzQxMzZaGA80NzU4MDMxMDA3 NDEzNlowgaYxCzAJBgNVBAYTAktSMRQwEgYDVQQIDAtHeWVvbmdnaS1kbzERMA8G A1UEBwwISHdhc2VvbmcxDjAMBgNVBAoMBVJ1bklUMQ4wDAYDVQQLDAVDbG91ZDEo MCYGA1UEAwwfUnVuSVQuQ2xvdWQgQ0EgUm9vdCBDZXJ0aWZpY2F0ZTEkMCIGCSqG SIb3DQEJARYVd2VibWFzdGVyQHJ1bml0LmNsb3VkMFkwEwYHKoZIzj0CAQYIKoZI zj0DAQcDQgAEquz+t68EzC+xVpjdqH+1k5D7xDjIboRzXi/m/dDsGWceXlwlw385 JHWQujPEqE4tIjY/UoS94DtNUjaoeABxFzAKBggqhkjOPQQDAgNJADBGAiEA8syO fe6lOTE28ntDB1mUsJAheBEWqxc87+YZNj05Gn0CIQCKDZTwr3W91eRERx/B3+hh JY7KdQNx3ZqiutJu/L4JRQ== —–END CERTIFICATE—–

NGINX SSL 설정하기

NGINX 기본 설치 후 SSL 인증서를 복사하고 적용합니다.

SSL 인증서 복사하기

[cp -arp /root/ssl /etc/nginx/]

/etc/nginx/nginx.conf 파일에 SSL 설정 추가하기

다음 구문의 주석(#)을 해제하고 server.key 와 server.pem 파일 경로를 설정합니다.

[vi /etc/nginx/nginx.conf] [root@runit ssl]# vi /etc/nginx/nginx.conf # Settings for a TLS enabled server. # server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name _; root /usr/share/nginx/html; ssl_certificate “/etc/nginx/ssl/server.pem”; ssl_certificate_key “/etc/nginx/ssl/server.key”; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers PROFILE=SYSTEM; ssl_prefer_server_ciphers on; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }

NGINX 설정 확인하기

[nginx -t] [root@runit ssl]# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

NGINX 서비스 재실행하기

[systemctl restart nginx]

자체 서명된 루트 인증서를 개인 컴퓨터에 설치해서 웹 서버 인증하기

개인 컴퓨터 호스트 추가하기

네임 서버( DNS)에 등록되지 않은 도메인으로 테스트하기 때문에 개인 컴퓨터에서 www.in.runit.cloud의 IP 주소를 호스트 파일에 추가해야 접속할 수 있습니다.

www.in.runit.cloud 호스트 추가하기

관리자 계정으로 Windows key + R 키를 눌러서 명령 프롬프트를 실행합니다.

notepad 명령으로 hosts 파일을 열어서 내용을 추가합니다.

[notepad C:\Windows\System32\drivers\etc\hosts] [root@runit ssl]# notepad C:\Windows\System32\drivers\etc\hosts # Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a ‘#’ symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 192.168.33.33 www.in.runit.cloud

루트 인증서(CA) 설치하기

윈도우 익스플로러 실행 후 https://www.in.runit.cloud 사이트에 접속합니다.

추가 정보 클릭 -> 웹페이지로 이동(권장하지 않음) 클릭하기

SSL 인증서 경고화면

인증서 오류 클릭 -> 인증서 보기 클릭하기

SSL 인증서 보기

인증 경로 클릭하기

‘ 신뢰된 인증 기간에서 이 인증서를 검증할 수 없습니다. ‘ 라는 메세지를 확인할 수 있습니다.

SSL 인증서 검증 불가

RunIT.Cloud CA Root Certificate 인증서 클릭 -> 인증서 보기 클릭하기

CA Root Certificate 인증서 보기

인증서 설치(i) 클릭하기

SSL 인증서 설치하기

인증서 가져오기 마법사 -> 현재 사용자(C) 선택 후 다음 클릭하기

SSL 인증서 가져오기 마법사

모든 인증서를 다음 저장소에 저장(P) 클릭 -> 찾아보기(R) 클릭 -> 신뢰할 수 있는 루트 인증 기관 확인 클릭 -> 다음(N) 클릭하기

신뢰할 수 있는 루트 인증 기관에 저장하기

인증서 가져오기 마법사 완료 -> 마침(F) 클릭하기

인증서 가져오기 마법사 완료

이 인증서를 설치하시겠습니까? -> 예(Y) 클릭하기

SSL 인증서 설치 경고

가져오기를 완료했습니다. -> 확인 클릭하기

SSL 인증서 가져오기 완료

웹 사이트 재접속하기

웹 브라우저를 재실행 해야 CA 루트 인증서가 적용됩니다.

윈도우 익스플로러를 종료하고 다시 실행해서 https://www.in.runit.cloud 사이트에 접속합니다.

인증서 오류 없이 신뢰할 수 있는 사이트로 보이는 것을 확인할 수 있습니다.

신뢰할 수 있는 사이트 확인 완료

마무리

사설 SSL 인증서를 생성하고 PC에 설치해서 사용하는 방법에 대해 알아보았습니다.

외부에 오픈된 서비스가 아니라 사내에서 사용할 때나 개인 테스트용으로 사설 SSL 인증서를 사용할 수 있습니다.

“빅테크보다 더 편하게” 사설인증서 뛰어드는 시중은행

[데일리임팩트 임은빈 기자] ‘천송이 코트’ 해프닝을 낳으며 역사 속으로 사라진 공인인증서 제도를 대체하기 위해 주요 시중은행들이 사설인증서 시장에 뛰어들었다. 빅테크 업체들도 시장에 참여해 다양한 서비스를 제공하고 있어 은행권과의 경쟁은 더 치열해질 전망이다.

11일 금융권에 따르면 KB국민은행은 오는 15일부터 ‘손택스(모바일 홈택스)’에서도 모바일인증서만을 통해 연말정산을 간편하게 이용할 수 있는 서비스를 출시한다고 밝혔다.

KB모바일인증서는 금융기관 최초로 ‘공공분야 전자서명’ 시범사업에 최종 선정됐으며 KB국민은행을 처음 거래하는 고객도 본인명의 스마트폰과 신분증만 있으면 영업점 방문 없이 발급할 수 있다. 패턴, 지문으로만 간편하게 로그인하고 6자리 간편비밀번호만 입력하면 금융거래가 가능하다.

아울러 KB모바일인증서는 ‘정부24’, ‘청약홈’등 52개의 공공서비스에 도입돼 간편인증서비스를 제공하고 있다. KB금융그룹 내 계열사 비대면 채널에서도 이용할 수 있으며 KB증권 모바일앱에서 KB모바일인증서로 로그인할 경우 추가 인증 없이 주식매매, 뱅킹거래 등 모든 거래가 가능하다.

KB국민은행 관계자는 데일리임팩트에 “KB모바일인증서의 활용 범위를 공공·민간기관 등으로 확장해 일상생활에서 친숙하고 편리한 인증서비스를 제공하는 국민인증서 역할을 해나가겠다”며 “KB모바일인증서로 편리하게 연말정산 서비스를 이용하길 바란다”고 말했다.

신한은행은 지난해 9월 국내 금융권 최초로 전자서명인증사업자로 선정됐다. 전자서명인증사업자 인정은 홈텍스 등 공공분야 전자서명사업, 마이데이터 통합인증사업 등에 참여하기 위해 반드시 필요한 절차다. 이는 공인인증제도 폐지 이후 전자서명인증 서비스의 신뢰성과 안정성 확보를 위해 도입한 제도다.

신한은행은 기존에 신한 쏠(SOL) 인증을 신한 사인으로 개편했다. 신한 사인은 신한 쏠(SOL)에서 30초만에 간편하게 발급 가능하며 본인인증 또는 전자서명 필요 시 간편 비밀번호, 지문, Face ID로 손쉽게 인증절차를 마칠 수 있다.

하나은행도 지난달 30일 전자서명인증사업자로 선정됐다. 하나은행은 전자서명인증사업자 선정을 위해 지난해 하반기 금융보안원을 평가기관으로 선정하고 약 180여개 항목에 대한 서면·현장평가를 거쳤다. 현재는 마이데이터 통합인증 서비스 제공도 준비 중이다.

우리은행과 NH농협은행은 올 상반기 서비스 출시를 목표로 사설인증서 개발을 한창 진행 중이다. 내부적으로 인증사업팀을 구성했으며 공공기관 참여, 전자서명인증사업자 선정, 마이데이터 통합인증 참여를 준비하고 있다.

시중은행들의 사설인증서 시장 참여에 가장 큰 라이벌은 빅테크 업체들이다. 지난 2020년 12월 출시된 카카오 인증서는 출시 1년 만에 이용자가 3000만명을 넘어섰고 패스 3200만명, 네이버 2200만명을 기록했다. 은행권 선두인 ‘KB모바일인증서’는 960만명을 기록했다.

시중은행의 한 관계자는 데일리임팩트에 “많은 논란 끝에 공인인증서가 폐지되고 사설인증서가 도입된 만큼 편리한 서비스로 국민들의 금융생활뿐 아니라 일상생활의 다양한 분야에서 간편한 인증 서비스를 제공할 것”이라고 강조했다.

공동인증서, 금융인증서, 토스인증서 뭐가 다른가요?

3줄 요약 온라인상에서는 본인임을 증명하기 위해 ‘전자서명’이 필요해요.

정부기관이 보증하는, 전자서명을 할 수 있던 공인인증서는 폐지됐어요. 대신 공동인증서, 금융인증서, 사설인증서를 쓸 수 있어요.

토스인증서는 정부의 보증을 받은 사설인증서로, 본인확인기관 라이센스와 전자서명인증사업자 라이센스를 모두 획득한 유일한 사업자예요. 그렇기 때문에 안심하고 사용할 수 있어요.

정부기관에서 서류를 발급받거나 은행 거래를 하다 ‘공인인증서’를 만나 씨름했던 경험히 한 번쯤은 있을 거예요. 하드디스크나 USB에 공인인증서가 없어서, 아니면 내 컴퓨터에서 공인인증서를 실행할 수 없어서 몇 시간이고 시도하다 결국 포기하고 동사무소나 은행 점포를 방문하기도 했죠. 이렇게 불편한 공인인증서, 왜 필요했던 걸까요? 토스인증서

‘나’임을 증명하기 위해 필요해요

우리가 어떤 계약을 한다고 가정해볼게요. 부동산 계약일 수도 있고, 근로계약일 수도 있을 텐데요. 이 때 꼭 빠지지 않는 절차가 ‘서명’이에요. 내가 계약 내용을 확인했고, 동의하며 계약의 내용에 책임을 진다는 의미로 인감도장을 찍거나 날인을 하죠. 서명이 있는 계약서를 잘 보관해야만 계약서 내용대로 책임을 지거나 보상을 받을 수 있고요.

마찬가지로 온라인에서도 ‘전자서명’이 필요해요. 금전거래를 하거나 개인정보가 포함된 서류를 발급받을 때 본인임을 확인할 수 있는 수단이 필요한 거죠. 이처럼 신원을 확인하고, 문서가 위조됐거나 변조됐는지 확인하고, 거래사실을 증명하기 위한 전자서명을 만들기 위해 사용했던 것이 공인인증서인데요. 공인인증서 안에는 발행기관 식별정보, 가입한 사람의 이름과 식별정보, 전자서명 검증키, 인증서 일련번호, 유효기간 등이 포함되어 있어요. 이용하는 사람은 ID와 비밀번호만 입력했을 때 만들어진 전자서명을 사용하는 방식이었고요.

인감도장을 잃어버리면 안 되는 것처럼 전자서명도 보안이 튼튼해야겠죠. 그래서 그동안은 행정안전부에서 지정한, 공신력 있는 기관에서만 공인인증서를 발급할 수 있었어요. 그래서 금융결제원, 한국정보인증, 한국증권전산(코스콤), 한국전자인증, 한국무역정보통신(트레이드사인), 이니텍 등 6곳에서만 공인인증서를 발급할 수 있었고요. 은행이나 증권사에서도 공인인증서 발급받을 수 있지 않냐고요? 맞아요! 그런데 그건 은행과 증권사가 직접 공인인증서를 발급하는 게 아니라 접수와 등록을 대신 해준 거예요. 실제 발급은 위에서 말한 6개 기관에서만 가능했고요.

그런데 불편한 점이 많았어요

일단 공인인증서의 종류가 2가지였다는 사실 아셨나요? ‘범용 공인인증서’와 ‘용도제한용 공인인증서’로 나뉘어지는데요. 우리가 대부분 쓰고 있던 건 용도제한용 공인인증서로 은행⋅카드⋅보험용⋅증권⋅관세청 등 정해진 용도로만 사용할 수 있었어요. 분야별로 인증서도 따로 발급받아야 했고요. 반면, 범용 공인인증서는 모든 분야에서 사용할 수 있지만 개인이라면 연간 4,400원의 발급 수수료가 있었어요.

사용성의 불편함도 있었어요. 일단 발급절차가 복잡했고요. 공인인증서를 실행하기 위해서는 Active X와 같은 보안프로그램을 다수 설치해야 했어요. 또한, 공인인증서 프로그램은 MS익스플로러에 최적화되어 있었기 때문에 Mac 등의 기기나 크롬 등 다양한 브라우저, 모바일 기기 등에서는 제대로 작동하지 않을 때도 있었죠. 유효기간도 1년으로 매년 직접 갱신해야 하는 불편함도 있었고요.

이러한 불편함을 감수했던 이유는 바로 ‘보안’ 때문이었는데요. 공인인증서의 안전성에 대한 신뢰도 계속 낮아지던 상황이었어요. 사람들은 공인인증서를 PC나 USB, 모바일 등에 저장해서 사용했는데 이때 일반 폴더(NPKI)에 저장되었기 때문에 파일을 해킹하는 게 어렵지 않았어요. 실제로 2020년, 금융결제원의 공인인증서 4만여 건이 해킹당하기도 했죠. 당시 금전 피해는 없었지만 공인인증서 내에는 다양한 개인정보가 담겨 있는 만큼 심각한 문제로 인지됐어요.

그래서 공인인증서를 없애기로 했어요

2020년 12월 10일, 전자서명법 개정으로 21년동안 사용됐던 ‘공인인증서’가 폐지됐어요. 그렇지만 전자서명할 방법이 없어졌다는 말은 아니에요. 여전히 온라인 상의 거래나 신분 확인은 이전보다 더 활발히 일어나고 있으니까요. 대신 다음과 같은 변화가 생겼어요.

1. 공인인증서의 이름이 ‘공동인증서’로 바뀌었어요

그동안 6개 기관에서 발행하는 인증서만 ‘공식적으로 인정해서 의무적으로 사용하던’ 지위가 사라진 거예요. 그렇기 때문에 이름도 ‘공인’인증서에서 ‘공동’인증서로 바뀐 거고요. 여전히 공동인증서를 발급받아 전자서명하는 데 사용할 수 있어요. 이전의 공인인증서의 특징(PC 보안 프로그램 설치 필요, 1년 수동갱신, 사용자 기기에 저장 등)도 유지돼요.

2. 금융인증서가 생겼어요

공동인증서가 PC, 스마트폰, USB 등 사용자의 기기에 인증서를 저장하는 거라면, 금융인증서는 금융결제원의 클라우드 서버에 저장해서 언제 어디서나 전자서명을 할 수 있도록 만든 거예요. 금융결제원과 은행권이 공동으로 만든 인증서비스로, 인터넷뱅킹이나 모바일뱅킹을 이용하는 은행 고객은 누구나 무료로 이용할 수 있어요. 1인당 1개를 발급받을 수 있고요. 별도의 보안 프로그램을 설치하지 않아도 괜찮아요. 인증서의 유효기간은 3년으로 자동갱신되고요.

3. 사설인증서가 생겼어요

은행뿐만 아니라 기업에서도 인증서를 만들기 시작했어요. 대표적으로 통신3사에서 만든 PASS(패스), 카카오페이인증, 네이버 인증서, 토스인증서 등이 있죠. 그중에서도 토스인증서 소개를 해보려고 해요.

Q. 토스인증서, 어떻게 사용하나요?

크게 3가지를 인증하는데 쓸 수 있어요.

본인확인: 주민등록번호 수준의 확인이 필요한 회원가입, 비밀번호 변경, 결제 전 인증에 사용해요.

주민등록번호 수준의 확인이 필요한 회원가입, 비밀번호 변경, 결제 전 인증에 사용해요. 간편인증: 간단한 로그인을 할 때나 계정을 조회할 때 사용할 수 있어요.

간단한 로그인을 할 때나 계정을 조회할 때 사용할 수 있어요. 전자서명: 계좌 개설, 보험 가입, 대출 신청 시 각종 전자문서에 서명할 때 사용할 수 있어요.

Q. 토스인증서, 어디에 쓸 수 있나요?

400여 기관에서 이용할 수 있어요. 크게 공공기관, 금융권, 생활영역으로 나눌 수 있는데요.

공공기관: 행안부 국민비서, 정부24, 국민건강보험공단, 대한법률구조공단, 민방위 사이버센터, 경기도청, 대구광역시청, 광주광역시청 등

행안부 국민비서, 정부24, 국민건강보험공단, 대한법률구조공단, 민방위 사이버센터, 경기도청, 대구광역시청, 광주광역시청 등 금융권: SC제일은행, 부산은행, 대구은행, 전북은행, 미래에셋대우, 키움증권, KB증권, 삼성생명, 교보생명, KB생명, 토스뱅크, 토스증권 등

SC제일은행, 부산은행, 대구은행, 전북은행, 미래에셋대우, 키움증권, KB증권, 삼성생명, 교보생명, KB생명, 토스뱅크, 토스증권 등 생활: 11번가, 롯데멤버스, 케이카, SK렌터카, KT알뜰폰, KT m&s 온라인몰, KFC, 할리스 등

11번가, 롯데멤버스, 케이카, SK렌터카, KT알뜰폰, KT m&s 온라인몰, KFC, 할리스 등 기타: 8퍼센트, 한국문화예술위원회, 한국건설기술인협회, 중소기업중앙회 등

Q. 토스인증서, 안전한가요? 믿고 쓸 수 있나요?

네 그럼요! 사설인증서도 공동인증서와 마찬가지로 정부의 인증과 보증을 받아야 해요. 그중에서도 토스인증서는 가장 안전하고 믿을 수 있다고 자부하는데요. 토스는 2021년 8월 방송통신위원회로부터 본인확인기관으로 지정되었고, 11월 한국인터넷진흥원으로부터 전자서명 인증사업자로 인정받았어요. 핀테크 회사 중 최초로 전자서명인증사업자 인정을 받은 본인확인기관이고요.

Q. 토스 인증서는 신분증 인증을 하더라고요. 이유가 있나요?

온라인상에서는 토스인증서가 신분증처럼 사용되기 때문에, 가장 정확하게 본인정보를 확인한 뒤 인증서를 발급하기 위해서예요. 위에서 언급한 본인확인기관과 전자서명인증사업자를 가진 기관이라면 반드시 지켜야 할 의무사항이기도 하고요.

신분증 정보를 포함한 모든 개인정보는 정부의 가이드라인을 준수하며 보관하고 관리해요. 개인정보를 어떻게 운영하고 있는지 정기적으로 평가받고 있으니 안심하고 이용해도 괜찮아요.

Q. 토스인증서, 얼마나 편리한가요?

토스인증서를 한번 발급받으면 PIN번호 또는 생체인증만으로 인증할 수 있어요. 인증할 때마다 이름, 휴대폰 번호, 생년월일을 입력하지 않아도 된다는 거죠. 복잡한 보안 프로그램 설치도 필요없고요. 한 번 발급받으면 3년 동안 유효하고, 만료 한 달전에 알려줄 텐데요. 이때 사용중인 PIN 번호나 생체인증을 진행하면 자동으로 갱신돼요.

간편 로그인부터 공공서비스까지,

토스인증서로 완벽한 인증 경험을 해보세요 토스인증서 발급받기

사설 인증서 생성하기 – 상구리의 기술 블로그

Table of Content

사설 인증서 생성하기

참고

참고

사설 인증서 생성

루트 인증서 생성

openssl ecparam -out rootCA.key -name prime256v1 -genkey

openssl req -new -sha256 -key rootCA.key -out rootCA.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —– Country Name (2 letter code) [AU]:KR State or Province Name (full name) [Some-State]:Seoul Locality Name (eg, city) []:Seoul Organization Name (eg, company) [Internet Widgits Pty Ltd]:Home Organizational Unit Name (eg, section) []:Home Common Name (e.g. server FQDN or YOUR name) []:Lee Email Address []:[email protected] Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: An optional company name []:

openssl x509 -req -sha256 -days 999999 -in rootCA.csr -signkey rootCA.key -out rootCA.crt

서버용 인증서 생성

웹서버 등에서 사용될 인증서를 생성합니다.

openssl ecparam -out server.key -name prime256v1 -genkey

openssl req -new -sha256 -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —– Country Name (2 letter code) [AU]:KR State or Province Name (full name) [Some-State]:Seoul Locality Name (eg, city) []:Seoul Organization Name (eg, company) [Internet Widgits Pty Ltd]:Home Organizational Unit Name (eg, section) []:Home Common Name (e.g. server FQDN or YOUR name) []:Lee Email Address []:[email protected] Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: An optional company name []:

extention.ext 파일을 생성합니다.

파일의 내용은 아래의 내용으로 합니다.

alt_names 탭에 원하는 도메인을 추가해 줍니다.

authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = localhost DNS.2 = *.localhost

아래 명령으로 인증서(crt) 파일을 생성합니다.

openssl x509 -req -sha256 -days 999999 -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -extfile extention.ext

인증서가 정상적으로 생성되었는지 확인할 수 있습니다.

openssl x509 -in server.crt -text -noout

사설 인증서 적용

스프링 부트

cat server.crt rootCA.crt > server.pem

openssl pkcs12 -export -inkey server.key -in server.pem -out key.pkcs12 -name System Enter Export Password: Verifying – Enter Export Password:

application.yml 파일에 아래 내용을 입력합니다.

server: ssl: enabled: true key-store: key.pkcs12 key-store-password: # 비밀번호를 입력한 경우 key-store-type: PKCS12 key-alias: System # Name 에 입력한 것

프로젝트 루트에 key.pkcs12 를 추가 후 프로젝트를 실행합니다.

https://localhost:8080/ 에 접속하면 SSL 이 활성화된 것을 확인할 수 있습니다.

Node JS

const path = require(“path”); const express = require(‘express’); const http = require(‘http’); const https = require(‘https’); const fs = require(‘fs’); const HTTP_PORT = 8080; const HTTPS_PORT = 8443; const options = { // key: fs.readFileSync(‘./rootCa.key’), // cert: fs.readFileSync(‘./rootCa.crt’) key: fs.readFileSync(‘./server.key’), cert: fs.readFileSync(‘./server.crt’) }; const app = express(); app.use(“/”, (req, res)=>{ res.sendFile(path.join(__dirname, ‘./index.html’)); }) const HTTPServer = http.createServer(app).listen(HTTP_PORT); const HTTPSServer = https.createServer(options, app).listen(HTTPS_PORT);

Linux (Ubuntu, Debian)

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

브라우저 크롬은 OS 인증서 대신 자체 인증서로 체크합니다.(https 작동안함)

Linux (CentOs 6)

sudo yum install ca-certificates sudo update-ca-trust force-enable sudo cp rootCA.crt /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust extract

Linux (CentOs 5)

sudo cat rootCA.crt >> /etc/pki/tls/certs/ca-bundle.crt

Windows 10

Reboot Required!!!

관리자 권한으로 도스창에서 아래 명령을 입력합니다.

재부팅 하면 경고창 없이 https://localhost:8080/ 를 접속할 수 있습니다.

certutil -addstore -f “ROOT” rootCA.crt

Mac OS X

키워드에 대한 정보 사설 인증서

다음은 Bing에서 사설 인증서 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.

이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!

사람들이 주제에 대해 자주 검색하는 키워드 [월요지식회] EP.28 공인인증서 폐지! 사설인증서 삼국지시대 개막?!(Feat. 통신. 페이. 은행)

• 동영상
• 공유
• 카메라폰
• 동영상폰
• 무료
• 올리기

[월요지식회] #EP.28 #공인인증서 #폐지! #사설인증서 #삼국지시대 #개막?!(Feat. #통신. #페이. #은행)

---

YouTube에서 사설 인증서 주제의 다른 동영상 보기

주제에 대한 기사를 시청해 주셔서 감사합니다 [월요지식회] EP.28 공인인증서 폐지! 사설인증서 삼국지시대 개막?!(Feat. 통신. 페이. 은행) | 사설 인증서, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.