개요
이 문서는 WiKID Strong Authentication 서버를 처음 설치할 때 필요한 인증서 체인 구성 과정을 단계별로 설명합니다. 주요 흐름은 다음과 같습니다: 중간 CA 생성 → CSR 생성 → WiKID CA에 CSR 제출 → 서명된 인증서 수신 및 설치 → localhost용 클라이언트 인증서 생성 → wAuth 서버 재시작.
정의(한 줄):
- CA: 인증서를 발급하고 관리하는 인증기관입니다.
- CSR: 인증서 서명을 요청하기 위한 공개키 정보와 식별자 정보가 포함된 파일입니다.
- PKCS12: 공개키/개인키를 하나의 패키지로 암호화해 저장하는 표준 형식입니다.
- localhost: 로컬 시스템을 가리키는 호스트명으로, 내부 서비스 인증에 사용됩니다.
중요: 인증서 체인은 서버의 인증 및 네트워크 클라이언트 식별에 필수입니다. 개인키를 잃으면 복구할 수 없습니다. 절대 분실하지 마세요.
준비 사항
- 관리자 권한으로 WiKID 서버에 접근 가능해야 합니다.
- 인터넷 접속(또는 조직 내 CA 접속)을 통해 WiKID CA로 CSR을 제출할 수 있어야 합니다.
- 안정적인 이메일 주소(중간 CA 관리자 이메일)를 준비하세요.
- 복구 불가능하므로 강력하고 기억 가능한 passphrase를 준비하세요.
중요: Passphrase는 어디에도 저장되지 않습니다. 분실 시 중간 CA를 다시 생성해야 합니다.
1단계: 중간 CA 생성
서버 관리 인터페이스에서 “중간 CA 생성” 탭을 선택합니다. 이 폼은 서버 식별 및 CSR 생성에 필요한 정보를 수집합니다. 모든 필드는 필수입니다.
그림 3 - 초기 관리자 페이지 스크린샷
폼 항목 설명:
- 중간 CA 관리자 이메일: 서명된 인증서를 받을 유효한 이메일 주소입니다.
- 서버의 정규화된 도메인 이름 (FQDN): DNS에 등록된 공식 호스트명입니다. SSL 클라이언트는 접속하려는 호스트명과 일치해야 합니다.
- 조직 단위: 부서 또는 팀 이름(식별용).
- 조직 이름: 서버를 운영하는 회사명. WiKID의 발급 프로세스를 빠르게 하기 위해 일치시키세요.
- 지역(Locality): 일반적으로 시(city) 이름입니다.
- 주/도(State): 주 또는 도 이름입니다(약어 사용 금지 권장).
- 국가 코드: 두 글자 국가 코드(예: US).
- Passphrase: 개인키를 PKCS12 형태로 암호화할 때 사용하는 암호입니다. 서버 시작 시 필요하며, 분실하면 복구 불가합니다.
생성 버튼(Generate)을 클릭하면 공개/개인키 쌍과 CSR이 생성됩니다. 생성 후 CSR은 base64 DER 인코딩으로 제공됩니다. 텍스트 박스의 모든 내용을 선택해 복사하세요.
그림 4 - 중간 인증기관 생성 화면
그림 5 - 생성된 CSR 예시
주의: CSR 텍스트에는 앞뒤의 —–BEGIN CERTIFICATE REQUEST—– / —–END CERTIFICATE REQUEST—– 라인이 포함되어야 합니다.
2단계: CSR 제출
CSR을 WiKID Systems CA로 제출합니다. 관리자 화면의 CSR 제출 링크를 클릭하거나 아래 URL로 이동합니다:
https://www/wikidsystems.com/wikid/newcertreq.jsp
웹 폼에 CSR 텍스트(—- 라인 포함)를 붙여넣고 제출하세요. 제출 후 요청 번호를 받게 되며, WiKID CA 관리자가 알림을 받고 처리합니다.
그림 6 - CSR 제출 화면
제출 처리 완료 후 이메일로 서명된 인증서 블록을 받습니다. 일반적으로 1 영업일 이내에 처리됩니다.
그림 8 - 이메일로 수신한 서명된 인증서 블록 예시
중요: 이메일 클라이언트(예: Outlook, Gmail)가 텍스트 인코딩을 변환할 수 있으므로, 인증서 블록을 잘라붙기할 때 반드시 일반 텍스트로 붙여넣기 하세요.
3단계: 서명된 중간 CA 설치
서명된 인증서를 수신하면 관리자 인터페이스의 “중간 CA 설치“ 탭으로 돌아가서 Install(설치) 옵션을 선택합니다. 이메일로 받은 인증서 텍스트를 제공된 텍스트 영역에 붙여넣고, 1단계에서 사용한 Passphrase를 입력한 뒤 설치를 진행합니다.
그림 9 - 인증서 설치 화면
문제 해결 팁:
- Passphrase 오류가 발생하면 입력값을 재확인하세요.
- 붙여넣기가 실패하면 메모장(또는 텍스트 편집기)을 경유해 일반 텍스트로 붙여넣기 하세요.
- Passphrase를 잊은 경우 1단계부터 다시 진행해야 합니다.
4단계: localhost용 클라이언트 인증서 생성
인증 서버와 직접 통신하는 모든 로컬 프로토콜 및 모듈은 인증서로 신원을 확인해야 합니다. 일부 프로토콜(RADIUS, LDAP, wAuth 등)은 자체적으로 인증서 전송/검증을 제공하지 않을 수 있으므로, WiKID의 프로토콜 모듈이 이를 안전한 통신으로 투명하게 변환합니다. 따라서 로컬 서비스들은 서버가 발급한 인증서로 인증을 수행해야 합니다.
로컬 서비스에서 사용할 단일 인증서를 생성하려면 생성 화면에서 “Client’s Fully Qualified Domain Name” 또는 FQDN을 “localhost”로 지정해야 합니다. 반드시 정확히 “localhost”로 입력하세요.
폼 항목 설명:
- Client의 FQDN: 로컬 서비스에서 사용되는 호스트명(로컬의 경우 “localhost”).
- 조직 이름: 클라이언트를 운영하는 회사명.
- 지역: 도시 이름.
- 주/도: 주 또는 도 이름.
- 국가 코드: 두 글자 국가 코드.
- Client PKCS12 Passphrase: 생성된 클라이언트 인증서를 암호화하는 패스프레이즈.
- Passphrase 확인: 위 패스프레이즈를 다시 입력.
- Server Keystore Passphrase: 1단계에서 생성한 중간 CA의 passphrase.
생성 버튼을 누르면 PKCS12 패키지 위치가 제공됩니다. localhost용이라면 이미 적절한 위치에 설치됩니다.
그림 10 - 로컬 인증서 생성 화면
그림 11 - 생성된 PKCS12 파일 위치 안내 화면
5단계: wAuth 서버 재시작
서버에서 새로운 인증서를 사용하도록 wAuth 서비스를 재시작합니다. root로 로그인하여 다음 명령을 실행하세요:
wikidctl restart명령 실행 시 wAuth passphrase(1단계에서 설정한 passphrase)를 입력하라는 프롬프트가 나타납니다. 올바른 passphrase를 입력하면 서비스가 새로운 인증서를 사용하여 클라이언트 인증을 수행합니다.
자동화 팁: 매번 수동으로 입력을 피하려면 /etc/WiKID/security 파일 하나를 생성해 다음 한 줄을 추가할 수 있습니다(권한 관리에 유의).
WAUTH_PASSPHRASE=yourpassphrase보안 경고: 위 파일에 평문 패스프레이즈를 저장하는 것은 운영 편의성을 높이지만 보안 위험을 증가시킵니다. 파일의 소유자와 권한을 엄격히 제한하세요(예: chmod 600).
문제 해결(트러블슈팅) 및 예외 사례
- 인증서 불일치 오류: 클라이언트가 접속하는 호스트명이 인증서의 CN(FQDN)과 일치하는지 확인하세요. localhost 인증서는 로컬 서비스에서만 사용하세요.
- 패스프레이즈 분실: 중간 CA의 개인키는 복구 불가합니다. 중간 CA를 재생성해야 합니다.
- 이메일로 받은 인증서가 깨져 보이는 경우: 텍스트 인코딩 문제일 수 있습니다. 이메일에서 인증서 블록을 선택해 메모장(또는 텍스트 편집기)에 붙여넣고 저장 후 설치하세요.
- PKCS12 파일 위치를 찾을 수 없음: PKCS 생성 후 표시되는 경로를 확인하고, 파일의 권한이 적절한지 확인하세요.
대체 사례(언제 이 방식이 실패하는가):
- 내부 보안 정책으로 외부 CA 사용이 금지된 환경에서는 조직 내부 CA를 사용해야 합니다.
- 오프라인 환경에서는 CSR 제출이 불가능하므로 오프라인 CA 프로세스를 따라야 합니다.
보안 권장 사항
- Passphrase를 안전한 비밀번호 관리자에 보관하세요. 절대 이메일로 전송하지 마세요.
- /etc/WiKID/security 파일을 사용하는 경우 파일 권한을 600으로 설정하고 소유자를 root로 하세요.
- 중간 CA의 개인키는 가능한 오프라인 안전한 장소에 백업하세요. 백업은 암호화되어 있어야 합니다.
- 인증서 갱신 정책을 수립하세요. 만료 전에 충분한 기간을 두고 갱신 프로세스를 테스트하세요.
운영자 및 역할별 체크리스트
아래 체크리스트는 역할별로 설치·운영 시 반드시 확인해야 할 항목들입니다.
관리자(설치 전)
- WiKID 서버에 root 접근 권한 확보
- 유효한 관리자 이메일 준비
- DNS에 서버 FQDN 등록 확인
- 강력한 Passphrase 생성
설치 담당자(CA 및 인증서 생성)
- 중간 CA 생성 폼을 정확히 입력
- CSR을 복사해 WiKID CA에 제출
- 서명된 인증서 수신 후 원본 텍스트로 저장
- 서명된 인증서 설치 후 오류 로그 확인
운영자(서비스 가동)
- localhost 인증서 생성 및 설치 확인
- wikidctl restart 후 서비스 정상 동작 확인
- 인증 로그에서 실패 케이스 모니터링
간단한 SOP(표준작업지침) — 주요 단계 요약
- 관리자 페이지 접속 → 중간 CA 생성 탭 선택
- 모든 필드 입력 → Generate 클릭 → CSR 획득
- CSR 제출 페이지로 이동 → CSR 붙여넣기 → 제출
- 서명된 인증서 수신 → Install 탭에서 붙여넣어 설치
- localhost PKCS12 생성(필요 시) → 설치 확인
- root로 로그인 → wikidctl restart → passphrase 입력
Критерии приёмки (수용 기준):
- 중간 CA 설치 후 서버가 서명된 인증서를 사용해 클라이언트 인증을 수행해야 합니다.
- localhost로의 로컬 서비스 연결이 인증서 검증을 통과해야 합니다.
- 서비스 재시작 후 로그에 인증서 관련 치명적 오류가 없어야 합니다.
검사 항목 및 수락 테스트(테스트 케이스)
- 테스트 1: CSR 생성 시 모든 필드가 비어 있으면 제출이 차단되는지 확인.
- 테스트 2: CSR을 제출하고 요청 번호를 받는지 확인.
- 테스트 3: 서명된 인증서를 설치한 후 서버가 인증서 체인을 읽는지 확인.
- 테스트 4: 클라이언트(로컬 또는 원격)가 인증서 검증 실패 없이 접속되는지 확인.
- 테스트 5: passphrase를 틀리게 입력했을 때 적절한 오류 메시지가 출력되는지 확인.
각 테스트는 성공/실패 결과와 재현 단계, 로그 스냅샷을 포함해 문서화하세요.
대체 접근법 및 비교
- 자체 서명(Self-signed) 인증서: 간단하지만 클라이언트 측에서 신뢰할 루트 CA를 별도로 설정해야 합니다. 내부 테스트 환경에서만 권장합니다.
- 조직 내부 CA 사용: 보안 정책에 맞고 내부 발급 프로세스가 확립되어 있다면 이 방법을 사용하세요.
비교 요약:
- WiKID CA 서명: 운영 환경 권장, 중앙화된 발급 관리.
- 자체 서명: 빠르지만 확장성과 신뢰성 제한.
- 내부 CA: 정책적 요구사항 충족 가능, 외부 발급 의존도 제거.
의사결정 흐름(간단한 흐름도)
graph TD
A[설치 준비 완료?] -->|아니요| Z[준비 항목 점검]
A -->|예| B[중간 CA 생성]
B --> C[CSR 생성]
C --> D{CSR 제출 가능 환경인가?}
D -->|예| E[WiKID CA에 제출]
D -->|아니요| F[오프라인 CA 프로세스 수행]
E --> G[서명된 인증서 수신]
G --> H[중간 CA 설치]
H --> I[localhost 인증서 생성]
I --> J[서비스 재시작]
J --> K[운영 검증]감사 및 로그 확인 팁
- 설치 직후 /var/log/wikid 또는 WiKID가 사용하는 로그 경로에서 인증 관련 오류를 확인하세요.
- 인증 실패가 반복될 경우, 인증서 체인, 키 권한, passphrase 일치 여부를 우선 점검하세요.
간단 용어집 (1줄 정의)
- CSR: 인증서 서명을 요청하는 데이터 묶음.
- PKCS12: 인증서와 개인키를 암호화해 묶는 표준 컨테이너.
- CA: 인증서 발급 및 관리 주체.
- FQDN: DNS에 등록된 완전한 도메인 이름.
요약
- WiKID 초기 설치의 핵심은 중간 CA 생성과 서명된 인증서의 올바른 설치입니다.
- 개인키와 passphrase는 복구 불가능하므로 안전하게 관리하세요.
- localhost 인증서는 로컬 프로토콜 보안을 위해 반드시 생성해야 합니다.
- 설치 후 서비스 재시작과 로그 검증을 통해 운영 검증을 수행하세요.
중요: 설치 작업은 보안 민감 작업입니다. 절차를 문서화하고, 설치 전후의 상태를 기록해 두세요.
