개념 사전/정보보안 / 암호·인증서
개념 사전 · 프로그램

OpenSSL

오픈에스에스엘

은 와 여러 암호 기능을 제공하는 라이브러리 및 명령줄 도구 모음이다. 인증서 생성·내용 확인·검증과 실제 서버의 설정은 별도의 단계로 다루어야 한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

로고: OpenSSL 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.

01무엇이고, 어떤 일을 하나

  • 인증서·공개키·개인키의 형식과 필드를 확인한다.
  • ·체인·서명 등 암호 자료를 처리한다.
  • 연결 오류를 알고리즘·신뢰 경로·서버 이름 조건으로 나눠 진단한다.

02어떤 순서로 동작하나

  1. 입력 자료 구분

    인증서··공개키·개인키 중 무엇을 읽는지 확인하고 파일 형식을 맞춘다. 확장자만으로 안의 자료 종류를 확정하지 않는다.

  2. 구조 해석

    Subject·Issuer·SAN·유효기간·Key Usage 등 목적에 필요한 필드를 읽는다. 자기 서명 인증서의 수학적 검증과 사전 신뢰는 별개다.

  3. 문맥 검증

    검증 시 사용할 신뢰 앵커·중간 인증서·서버 이름·용도를 정한다. 단순 인증서 덤프 화면은 실제 접속 대상 인증 검증 결과와 다르다.

  4. 운영 반영 대조

    서버가 실제 제공하는 체인과 개인키 일치·지원 프로토콜·재적용 상태를 확인한다. 빌드 헤더와 런타임 라이브러리 버전도 장애 원인이 될 수 있다.

03먼저 알아둘 용어와 구성요소

암호 알고리즘과 관련 처리 기능을 제공하는 라이브러리.
프로토콜 기능을 제공하는 라이브러리.
등의 바이트를 와 경계 표식으로 감싼 텍스트 표현.
3 계열에서 알고리즘 구현 등을 제공하는 모듈 구조.
ASN.1 자료의 정규화된 이진 인코딩.
개인키로 서명하여 공개키와 신청 정보를 전달하는 인증서 발급 요청.
LEARN THROUGH PRACTICE

RSA 과제의 modulus와 서명 입력 바이트 읽기

modulus를 공개키 전체와 혼동하지 않고, 공개키 추출·서명·검증을 서로 다른 작업으로 구분한다.

실습 구성과 전제

  • 의 교육용 키 또는 자신이 만든 폐기 가능한 실습 키만 사용한다.
  • 작업 폴더에 키와 메시지를 분리해 저장하고 실제 운영 개인키는 가져오지 않는다.

  1. 과제가 요구하는 값을 구분한다

    • 공개키에는 modulus n과 공개 지수 e가 필요하다. modulus의 16진수 문자열만 저장한 파일은 일반적인 공개키 파일이 아니다.
    • 문제는 modulus 문자열을 구한 다음 그 문자열에 서명하라고 요청한다. 키를 암호화하는 작업이나 modulus 자체를 공개키 인증서로 바꾸는 작업이 아니다.
    shell
    openssl rsa -in lab-private.pem -modulus -noout
openssl pkey -in lab-private.pem -pubout -out lab-public.pem

    자신의 폐기 가능한 실습 키에서 modulus를 조회하고 공개키를 추출한다.

    WebGoat RSA 키 과제원본 크기로 보기 ↗
    • 화면은 개인 RSA 키를 교육용 입력으로 주고 modulus의 16진수 표현과 서명을 각각 요구한다.
    • BEGIN PRIVATE KEY 표시는 PEM 컨테이너의 시작이며, 답안 입력칸 두 개는 서로 다른 결과물을 받는다.
    확인 기준

    n만 추출한 파일과 공개키 파일을 이름부터 다르게 관리한다.

  2. 서명할 메시지의 바이트를 고정한다

    • 과제가 정한 16진수 대소문자·접두사·개행 포함 여부를 먼저 확인한다. 보이는 글자가 같아도 마지막 LF가 있으면 해시 입력이 달라진다.
    • 서명은 개인키로 수행하고 검증은 공개키로 수행한다. 는 생성된 서명 바이트를 답안에 넣기 쉬운 문자열로 바꾸는 표현이다.
    shell
    openssl dgst -sha256 -sign lab-private.pem -out signature.bin message.txt
openssl dgst -sha256 -verify lab-public.pem -signature signature.bin message.txt

    메시지 파일을 중간에 수정하지 않고 서명·검증한다. 사진의 개인키 값은 재사용하지 않는다.

    확인 기준

    서명 검증이 실패하면 키 쌍과 함께 메시지 파일의 실제 바이트를 비교한다.

  3. 키 소유 증명과 신원 신뢰를 나눈다

    • 서명이 맞다는 것은 해당 공개키에 대응하는 개인키가 사용됐다는 증거다. 그 키가 누구의 것인지는 별도의 신뢰 관계가 필요하다.
    • 인증서 체인은 공개키를 이름·용도·기간과 묶는다. 서명 과제와 인증서 검증 도해는 서로 다른 단계의 비교 자료다.
    인증서 체인 · 인증서 체인은 왜 필요한가원본 크기로 보기 ↗
    • 서버 인증서 위에 Intermediate CA와 Root CA가 연결돼 있다.
    • 오른쪽에는 서버 이름·유효기간·용도·폐기 상태가 따로 나열되어, 서명 확인만으로 검증이 끝나지 않음을 보여 준다.
    확인 기준

    서명 성공을 곧바로 서버 신뢰 성공으로 보고하지 않는다.

실습에서 확인한 동작 원리

  • modulus는 공개키의 한 구성 요소다.
  • 서명은 메시지의 정확한 바이트와 키 쌍에 의존한다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

브라우저 인증서 경고를 체인·이름·기간으로 나누기

HTTPS 경고를 무조건 암호화 실패로 해석하지 않고 신뢰 검증의 실패 지점을 찾는다.

실습 구성과 전제

  • 자신이 관리하는 실습 HTTPS 서버와 서버 인증서·중간 CA·실습 CA 파일을 준비한다.
  • 아래 도해와 브라우저 경고는 검증 원리와 실제 오류의 비교 자료이며 같은 서버의 연속 실행 증거가 아니다.

  1. 브라우저가 어떤 검증에서 멈췄는지 읽는다

    • 오류 코드와 접속 이름을 먼저 기록한다. NET::ERR_CERT_AUTHORITY_INVALID는 신뢰 가능한 발급 경로를 만들지 못했음을 조사할 출발점이다.
    • 원인은 신뢰 저장소에 없는 CA, 누락된 중간 인증서 등일 수 있다. 화면 하나로 개인키 손상이나 서버 침해를 확정하지 않는다.
    HTTPS 인증서와 브라우저 표시원본 크기로 보기 ↗
    • 주소는 HTTPS로 시작하지만 브라우저에 '연결이 비공개로 설정되어 있지 않습니다'가 표시된다.
    • 오류 코드가 NET::ERR_CERT_AUTHORITY_INVALID이므로 단순 HTTP 미사용 여부와 CA 신뢰 문제를 구분해야 한다.
    확인 기준

    경고를 무시해 접속하는 것을 해결로 기록하지 않는다.

  2. 인증서 필드와 체인을 따로 검사한다

    • Subject·Issuer는 표시 이름이며, 실제 서버 이름 비교에는 SAN을 본다. 기간은 현재 시계와 Not Before·Not After를 비교한다.
    • 신뢰 앵커는 클라이언트가 신뢰하도록 설정한 값이다. 서버가 루트 인증서를 함께 보낸다는 사실만으로 신뢰가 생기지 않는다.
    shell
    openssl x509 -in server.pem -noout -subject -issuer -dates -ext subjectAltName
openssl verify -CAfile lab-root.pem -untrusted intermediates.pem -verify_hostname lab.example server.pem

    보유한 인증서 파일을 로컬에서 검사하는 예시. lab.example은 실제 시험 이름으로 바꾼다.

    인증서 체인 · 인증서 체인은 왜 필요한가원본 크기로 보기 ↗
    • 체인은 Root CA→Intermediate CA→서버 인증서로 그려져 있다.
    • 검증 항목은 서명 체인 외에 서버 이름·기간·용도 제한·폐기 상태를 포함한다.
    확인 기준

    체인 검증 성공과 이름 검증 성공을 각각 기록한다.

  3. 수정한 조건만 재시험한다

    • 누락된 중간 인증서를 보완했다면 서버가 보내는 체인을 다시 확인한다. 실습 CA 신뢰를 추가했다면 그 클라이언트의 신뢰 저장소 변경 범위를 기록한다.
    • 이름이나 만료 조건까지 동시에 바꾸면 어느 변경이 경고를 없앴는지 알기 어렵다. 각 실패 조건을 분리해 재시험한다.
    확인 기준

    체인·SAN·기간이 모두 맞는 상태에서만 정상으로 판정한다.

실습에서 확인한 동작 원리

  • HTTPS 사용과 인증서 신뢰 성공은 별개다.
  • 오류 코드를 검증 조건에 연결하면 불필요한 설정 변경을 줄일 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 인증서에 기대한 이름의 SAN이 없으면 체인의 서명이 맞아도 호스트 이름 검증이 실패할 수 있다.
  • 파일 안의 CERTIFICATE와 PRIVATE KEY 표식은 다른 종류의 내용을 뜻하며 공개 범위도 다르다.
  • 라이브러리 버전 불일치 경고가 나타나면 암호문 문제로 단정하기 전에 프로그램과 로드된 라이브러리의 호환 관계를 확인한다.

05혼동하기 쉬운 점과 확인 기준

  • 개인키에 암호를 걸지 않는 옵션을 모든 서버의 기본 권장으로 복사하지 않는다. 서비스 실행과 키 보관 정책을 함께 결정한다.
  • 1.x·3.x의 옵션·지원 알고리즘·가 달라질 수 있으므로 오래된 명령의 성공 여부와 보안성을 분리한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

전자서명과 PKI 인증서 읽기전자서명은 데이터와 서명키의 관계를 검증한다. PKI는 공개키를 이름과 연결하고 그 연결을 신뢰하는 체계를 제공한다.상세 노트 읽기 →

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.