자체 서명 인증서용 RSA vs ECDSA
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‑256 ≈ RSA 3072 (128‑비트 보안)
- ECDSA P‑384 ≈ RSA 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을 포함하면 호스트 이름 불일치 오류를 방지하고 호환성을 높일 수 있습니다.