Cert-Gen

Certificate Generator. 인증서 생성기.

웹브라우저의 주소 표시줄에 자물쇠 표시를 만들어주는 그것.
자세한 내용은 여기를 보면 된다.

기본적으로 인증서 발급 기관을 통해서 Server용 인증서를 발급받지만 사내 도메인을 사용하거나, 폐쇄망의 환경에서는 자체 서명/발급 인증서를 사용한다.

보통의 경우는 여기의 내용처럼 openssl 어쩌구 명령을 수차례 날려야 하기에 매우 귀찮아서 조금이라도 쉽게 인증서 생성 과정을 처리해보고자 만든 도구다.

Github 바이너리 링크

Linux(Redhat, Debian, Ubuntu)와 Windows(10,11, Server 2019이상)을 지원한다.
Windows Defender에서 트로이목마로 인식하므로, 허용해서 쓰면 된다.

사용법

cert-gen tui
Terminal Ui를 이용해 작업한다.

haedongg.net:~/cert-gen]#    ./cert-gen --help

cert-gen 0.1.0 — 자가서명 인증서 생성기 (로컬 CA)

사용법:
  cert-gen [전역 옵션] <명령> [하위 명령] [옵션]

전역 옵션:
  --data-dir DIR    상태 디렉터리 (기본: <현재 디렉터리>/cert-gen-data)
  -c, --config FILE 설정 파일 (기본: <상태 디렉터리>/config.toml)
  --json            결과를 JSON 으로 출력
  -q, --quiet       사람이 읽는 출력을 생략
  -v, --version     버전 출력

명령:
  init                         상태 디렉터리와 DB 를 만든다
  where                        상태 디렉터리 위치와 규칙을 보여 준다
  doctor                       환경 점검 (권한·DB·CA·만료·CRL·openssl). --deep 으로 번들 해시까지

  key create --name NAME       개인키를 만들어 둔다 (CA·발급에서 고를 수 있다)
  key list                     개인키 목록 (쌍 토큰으로 인증서와 짝을 맞춘다)
  key show NAME                개인키 상세·사용처
  key import --file FILE        외부 개인키를 가져온다
  key passphrase NAME          패스프레이즈 설정/제거(--remove)
  key delete NAME              개인키 삭제 (쓰이는 중이면 거부)

  ca create                    Root CA 를 만든다 (--cn 필수, --org/--ou/--country)
  ca list                      CA 목록
  ca show SLUG                 CA 상세
  ca export SLUG               ca.crt 를 내보낸다 (클라이언트 신뢰 등록용)
  ca adopt --dir DIR           외부 CA 를 복사 없이 등록해 발급에 쓴다
  ca import --key K --cert C   외부 CA 를 상태 디렉터리로 복사해 등록한다

  apply FILE...                openssl .cnf 를 읽어 CA 생성·발급을 한 번에
                               (한 파일에 --- 로 블록을 나누거나, 파일을 여러 개 주거나)

  cert issue                   인증서를 발급한다 (--config 로 openssl .cnf 입력 가능)
  cert list                    발급 이력
  cert show REF                상세 (ID | serial | CN)
  cert renew REF               갱신 (기본: 새 키)
  cert revoke REF              폐기하고 CRL 을 다시 만든다
  cert verify REF              검증 (체인·호스트명·폐기)
  cert bundle REF              번들 zip 을 꺼낸다

  csr create                   외부 CA 제출용 CSR 을 만든다
  csr sign --csr FILE          받은 CSR 을 우리 CA 로 서명한다

  export p12 REF               PKCS#12
  export jks REF               Java KeyStore
  export der REF               DER
  export pem REF               PEM (cert/key/fullchain/ca)
  export k8s REF               kubernetes.io/tls Secret (+ Ingress)

  crl generate SLUG            CRL 을 다시 만든다
  crl list SLUG                폐기 목록

  backup create                상태 디렉터리 전체를 tar.gz 로 묶는다 (CA 개인키 포함)
  backup restore FILE          백업을 복원한다 (--dry-run 으로 먼저 확인)

  trust show [SLUG]            OS·Java 신뢰 저장소 등록 명령을 만든다
  tui                          터미널 UI 를 띄운다

비밀값은 명령행 인자로 받지 않는다 (/proc/<pid>/cmdline 노출).
환경변수나 --*-stdin 옵션, 또는 TTY 프롬프트를 쓴다.
  CERT_GEN_CA_PASSPHRASE, CERT_GEN_EXPORT_PASSWORD, CERT_GEN_KEY_PASSPHRASE

'cert-gen <명령> -h' 로 각 명령의 옵션을 본다.

SSL 그리고 HTTPS

SSL (Secure Socket Layer)

전송 계층 보안(영어: Transport Layer Security, TLS, 과거 명칭: 보안 소켓 레이어/Secure Sockets Layer, SSL)는 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. 그리고 ‘트랜스포트 레이어 보안’이라는 이름은 ‘보안 소켓 레이어’가 표준화 되면서 바뀐 이름이다. 이 규약은 인터넷 같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해준다. 이 규약은 웹 브라우징, 전자 메일, 인스턴트 메신저, voice-over-IP (VoIP) 같은 응용 부분에 적용되고 있다. 국제 인터넷 표준화 기구(IETF)에 의해 현재 구식(deprecate)으로 간주되어 있다. 최종 갱신은 RFC 5246이고, 최종 갱신 버전은 넷스케이프에서 만든 SSL 표준을 바탕으로 했다. 위키백과 발췌
용어 사용 시 SSL과 TLS를 구분해야 할 필요는 없다. 사실 TLS보다 SSL이 더 입에 잘 붙는다.

먼저 컴퓨터의 암호화에 대해 아주 쉽게 설명하면
컴퓨터는 0과 1만 존재한다 (on, off).
즉 컴퓨터는 숫자만 존재한다.
숫자 1,000이 있다고 가정하면 이 숫자 1,000이 아닌 것처럼 보이게 한다. = 암호화

예를 들어
1,000 X 100 = 10,000
1,000은 내가 암호화 하고 싶은 원본
곱하기는 ‘암호화 알고리즘’
100은 암호화를 위한 ‘키’ 가 되겠다.

여기에서 철수가 영희에게 금고의 비밀번호를 알려주는 상황을 적용해보자.
금고의 비밀번호는 1000이다.
비밀번호는 철수만 알고 있다.
주변에 사람이 많아서 비밀번호를 그냥 말하면 금고의 비밀번호가 노출된다.
보안을 위해 100이라는 숫자를 키로 하여 곱하기 알고리즘으로 암호화한다.
철수는 영희에게 ‘비밀번호는 10000이야. 곱하기 알고리즘으로 암호화 했어’ 라고 말한다.
여기까지가 기본적인 암호화,암호화 데이터 전송 순서가 되겠다.

하지만,
철수가 미리 영희에게 키를 알려줬다면 문제가 없겠지만 만약 영희는 아직 키를 모른다면?
의 경우에 대응하기 위해서 나온 기술이 바로 SSL 되시겠다. (엄밀히 말하면 좀.. 다르지만)

공개키 암호화와 비공개키 암호화 (=비대칭키 암호화와 대칭키 암호화)

개념상 두 종류의 자물쇠가 있다고 생각하면 편하고. 하나는 ‘잠그는 열쇠, 여는 열쇠가 따로 있는 자물쇠’ = A 다른 하나는 ‘잠글 때 열 때 같은 열쇠를 사용하는 자물쇠’ = B. SSL의 중요한 개념은 여기에 있다.

자물쇠 A : 소인수분해를 통해 소수(자기 자신과 1로만 나뉘어지는 수)를 찾아 내는 것이 쉽지 않다는 것에 기인하여 만들어진 알고리즘을 이용한다.11,2,3,5,7,11… 은 소수임을 금방 알아낼 수 있지만 10,000,000,000,000,001이 소수인지는 알아내기 쉽지 않다. 아직 특정한 수가 소수인지 아닌지 알아내는 방법은 없다(고한다. 난 산수 싫다. 어렵다.) 그래서 느리다(고 한다.)
잠그는 열쇠와, 여는 열쇠가 구분 되어있다. 열쇠 하나는 잠그는 것만 가능하고 하나는 여는 것만 가능하다.
잠글 때 쓰는 열쇠와 열 때 쓰는 열쇠가 다르다 = 비대칭 키
암호화,복호화 하는데 시간이 많이 걸린다.

자물쇠 B :열쇠 하나만 있으면 열고 잠그는 것이 가능하다.
잠글 때 쓰는 열쇠와 열 때 쓰는 열쇠가 같다 = 대칭 키
암호화, 복호화 하는데 시간이 덜 걸린다. (비대칭키 암호화 알고리즘에 비해)

위에서부터 순서대로 사건이 발생한다.
철수와 영희의 모든 대화는 가운데 도둑이 들을 수 있다.

위와 같은 절차로 Kk를 주고 받는 것이 ‘키 교환’ 알고리즘이 되겠다. (개념상으로 이렇다는 것만 이해하자. 실제 키를 주고 받는데엔 다양한 방법이 존재한다. DH, RSA 등이 포함되면 키를 교환하기 위한 수단이구나 생각하면 된다.)

HTTPS
언뜻 보면 완벽해 보이지만 여기에 큰 맹점이 하나 있다. 바로 도둑이 철수인 척 하여 중간에서 데이터를 가로채는 경우이다.
1. 철수에게서 받은 K1을 받는다.
2. K1#을 만들어 영희에게 전달한다
3. 영희는 K1#으로 Kk를 암호화 하여 도둑에게 전달한다.
4. 도둑은 K2#으로 복호화하여 Kk를 획득한다.
5. K1으로 Kk를 암호화 하여 철수에게 전달한다.
이후부터는 Kk로 암호화한 데이터가 오가므로 쉽게 복호화 할 수 있다.

즉, 철수와 영희는 실제 상대방이 누구인지 확인할 수 없다는 사실이다.
우리가 사용하는 SSL-HTTPS는 이를 보완하기 위한 제 3자 증명 과정이 추가된다.