자체 서명 인증서용 RSA vs ECDSA

발행: (2026년 5월 6일 PM 08:57 GMT+9)
6 분 소요
원문: Dev.to

Source: Dev.to

키 알고리즘 선택

자체 서명 인증서를 생성할 때는 키 알고리즘을 선택해야 합니다. 우리 생성기에서는 다음을 제공합니다:

  • RSA 2048
  • RSA 4096
  • ECDSA P‑256
  • ECDSA P‑384

간단한 권장 사항

  • ECDSA P‑256 – 모든 연동 서비스가 지원한다면 새로운 서비스의 기본값으로 사용합니다.
  • RSA 2048 – 가장 높은 호환성을 제공합니다; 인증서를 누가 사용할지 확신이 서지 않을 때 사용합니다.
  • RSA 4096 – 규정 체크리스트에 명시적으로 요구될 때만 사용합니다.
  • ECDSA P‑384 – 고신뢰 시나리오용; 대부분의 자체 서명 인증서에는 과도합니다.

성능 비교

ECDSA는 서명 속도가 현저히 빠릅니다:

알고리즘대략적인 서명 시간 (최신 CPU)
RSA 2048~1 ms
RSA 4096~6 ms (≈6배 느림)
ECDSA P‑256~0.04 ms (≈RSA 2048 대비 25배 빠름)

TLS 핸드쉐이크에서는 고트래픽 서버에서 차이가 날 수 있지만, 개발용 자체 서명 인증서에서는 큰 차이가 없습니다.

키 크기와 인증서 크기

알고리즘공개키 크기일반적인 인증서 크기
RSA 2048~294 bytes~1.2 KB
RSA 4096~550 bytes~1.8 KB
ECDSA P‑256~91 bytes~700 bytes

작은 인증서는 TLS 핸드쉐이크를 더 빠르게 하며, 특히 모바일 기기에서 유리합니다.

보안 강도

NIST는 동등 강도 표를 제공합니다:

  • ECDSA P‑256RSA 3072 (128‑비트 보안)
  • ECDSA P‑384RSA 7680 (192‑비트 보안)
  • RSA 2048 ≈ 112‑비트 보안 (≈2030년까지 허용)
  • RSA 4096 ≈ 140‑비트 보안

두 계열 모두 현재 알려진 고전적 공격에 대해 이 크기에서는 저항합니다. 양쪽 모두 양자 안전하지는 않으며, 충분히 큰 양자 컴퓨터(아직 존재하지 않음)가 있다면 두 알고리즘 모두 깨질 수 있습니다.

호환성

  • RSA – 보편적으로 지원됩니다. 지금까지 만들어진 모든 SSL/TLS 클라이언트가 RSA를 사용합니다.
  • ECDSA – 지원 환경:
    • 모든 최신 브라우저 (Chrome, Safari, Firefox, Edge – ~2013년부터 완전 지원)
    • curl, wget, OpenSSL, GnuTLS, BoringSSL
    • Go, Rust, Node.js, Python, Java 8+, .NET Core
    • 최신 Linux 배포판, macOS 10.9+, Windows 7+

ECDSA는 일부 매우 오래된 임베디드 장치, 특정 산업 제어 시스템, Java < 7, 그리고 일부 레거시 로드밸런서 펌웨어에서는 지원되지 않습니다. 이러한 환경과 연동해야 한다면 RSA를 선택하세요.

권장 사항

  • ECDSA P‑256 사용 – 더 빠르고, 더 작으며, 모든 주류 플랫폼에서 지원됩니다.
  • RSA 2048 사용 – 모든 클라이언트가 ECDSA를 지원한다는 보장이 없을 때 (예: 매우 오래된 장비).
  • RSA 4096 또는 ECDSA P‑384 사용 – 규정 체크박스를 만족시키기 위한 경우에만; 일반적인 자체 서명 인증서에 실질적인 보안 이점은 없습니다.
  • 양자 안전성 – 두 알고리즘 모두 양자 안전하지 않습니다. 포스트‑양자 알고리즘(예: ML‑DSA)이 표준화되면 인증서를 다시 발급해야 하므로, 오늘날 선택을 양자 위협에 근거해 결정하지 마세요.

Nginx에 인증서 설정하기

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /path/to/your/cert.pem;
    ssl_certificate_key /path/to/your/key.pem;

    # 선택 사항: 성능 향상을 위해 HTTP/2 활성화
    listen 443 ssl http2;
}

/path/to/your/cert.pem/path/to/your/key.pem을 도구를 사용해 생성한 자체 서명 인증서와 개인키 파일 경로로 교체하십시오.

SAN이 중요한 이유

Subject Alternative Names (SAN) 은 하나의 인증서로 여러 호스트 이름(예: example.com, www.example.com, api.example.com)을 보호할 수 있게 해줍니다. 최신 브라우저와 많은 TLS 구현은 SAN을 요구하며, 레거시인 Common Name 필드는 호스트 이름 검증에 무시됩니다. 자체 서명 인증서에 적절한 SAN을 포함하면 호스트 이름 불일치 오류를 방지하고 호환성을 높일 수 있습니다.

0 조회
Back to Blog

관련 글

더 보기 »

시스템 설계 트레이드오프

스케일링 - 수직 스케일링 vs 수평 스케일링 - 확장성 vs 성능 일관성 및 가용성 - 일관성 vs 가용성 CAP - 강한 일관성 vs 최종 일관성