ECC（Elliptic Curve Cryptography、楕円曲線暗号）は、RSA と並ぶ公開鍵暗号方式の一種です。短い鍵長で同等の安全性を実現できることから、TLS ハンドシェイクの高速化・サーバ負荷軽減の手段として、SSL/TLS 証明書でも標準的に採用されています。
- 新規構築・モダン環境なら ECC を推奨（高速・低負荷）
- 古い Windows XP / Android 2.x など旧環境サポート必須なら RSA
- 当店では FujiSSL / 主要ブランドとも ECC / RSA 両対応。CSR 作成時に選択可能
📊 ECC と RSA の比較
| 項目 | ECC | RSA |
|---|---|---|
| 鍵長 | 256 bit | 2048 bit |
| 暗号強度 | 128 bit セキュリティ | 112 bit セキュリティ |
| 署名速度 | 約 10 倍速い | 標準 |
| 検証速度 | 標準 | 速い（ECC より高速） |
| サーバ CPU 負荷 | 軽い | 標準 |
| 証明書サイズ | 小さい | 大きい |
| 互換性 | 2014 年以降の主要環境 | ほぼ全環境（XP 以降） |
| 主要曲線 | P-256、P-384、P-521 | ─ |
| NIST 推奨期限 | 2030 年以降も継続 | 2030 年で非推奨化検討中 |
同等の暗号強度に必要な鍵長
同じ「強さ」を実現するために必要な鍵長は、ECC の方が大幅に短くて済みます。
| セキュリティレベル | ECC 鍵長 | RSA 鍵長 |
|---|---|---|
| 112 bit（標準） | 224 bit | 2048 bit |
| 128 bit（推奨） | 256 bit | 3072 bit |
| 192 bit（高強度） | 384 bit | 7680 bit |
| 256 bit（最高） | 521 bit | 15360 bit |
「ECC 256 bit ≒ RSA 3072 bit」という関係になります。一般的な「RSA 2048 bit」より、現代の標準的な「ECC 256 bit」の方がやや暗号強度が高いことになります。
⚡ ECC のメリット
1. 処理速度が速い（特にサーバ側の署名処理）
短い鍵長で同等のセキュリティ強度を実現できるため、TLS ハンドシェイク時の CPU 負荷が大幅に軽減されます。サーバ側の署名処理は ECC の方が 約 10 倍高速です。
2. モバイル端末で有利
計算量が少ないため、スマートフォンでのバッテリー消費が抑えられ、初回接続のレスポンスも改善します。モバイルファーストのサービスほど効果が顕著です。
3. 高負荷サーバ・大規模サービスで効果大
EC サイト・SaaS・API サーバなど、毎秒大量の TLS ハンドシェイクを処理するインフラでは、ECC 移行による CPU 使用率削減が運用コスト削減に直結します。
4. 証明書サイズが小さい
送信される証明書チェーンが小さくなるため、初回接続時の通信量が削減されます。低帯域回線や IoT デバイスでメリットがあります。
5. 量子コンピュータ時代を見据えた将来性
現在、業界では耐量子計算機暗号（Post-Quantum Cryptography）への移行が議論されています。ECC は RSA と同様、長期的には新方式への置き換えが必要ですが、移行までの中期では ECC の方が安全マージンが高いとされています。
🔄 RSA を選ぶケース
以下のいずれかに該当する場合は、RSA を選択するのが安全です。
古い OS / ブラウザのサポートが必要
| 環境 | ECC 対応状況 | 備考 |
|---|---|---|
| Windows XP（IE / Chrome 旧版） | ❌ 非対応 | 2014 年 4 月にサポート終了 |
| Android 2.x 系 | ❌ 非対応 | 2010 年前後の端末 |
| Java 7 以前 | ⚠ 一部対応 | P-256 のみ対応 |
| 古い IoT / 組み込み機器 | ⚠ 要確認 | 機種ごとに対応状況が異なる |
| Windows 7 SP1 以降 | ✅ 対応 | P-256 標準対応 |
| Android 4.x 以降 | ✅ 対応 | P-256 標準対応 |
特定の業界規制・ガイドラインで指定がある
金融業界（FISC）・医療業界・公的機関など、内部規定で RSA 2048 bit を明示している場合は、それに従う必要があります。
既存システムとの互換性維持
大規模なエンタープライズ環境で、すべてのコンポーネント（API ゲートウェイ・ロードバランサ・古いミドルウェア等）の ECC 対応状況を確認できない場合、無理に移行せず RSA 継続が無難です。
🌐 採用が進む業界・サービス
主要な大手サイト・サービスでは、ECC 証明書の採用が広がっています。
- Google、Facebook、Twitter（X）など主要 SNS
- Amazon、楽天、ヤフーなどの大手 EC サイト
- Cloudflare、AWS CloudFront など主要 CDN
- 主要金融機関のオンラインバンキング
確認方法：ブラウザのアドレスバー左の鍵マーク → 証明書詳細 → 「公開鍵」項目で ECDSA または secp256r1 と表示されれば ECC 証明書です。
🛠 ECC 証明書の取得方法
当店および FujiSSL の主要ブランド証明書は、ECC / RSA いずれの鍵タイプにも対応しています。CSR 作成時に選択するだけで、ECC 証明書を発行できます。
OpenSSL で ECC の CSR を作成する例
# ECC 秘密鍵を生成（P-256 = secp256r1 = prime256v1）
openssl ecparam -genkey -name prime256v1 -out private.key
# CSR 作成
openssl req -new -key private.key -out request.csr \
-subj "/CN=www.example.com/O=Your Company/C=JP"
# CSR の内容確認（公開鍵が EC になっているか）
openssl req -in request.csr -text -noout | grep "Public Key"
# → Public Key Algorithm: id-ecPublicKey と表示されれば OK主要曲線の選び方
| 曲線名 | OpenSSL 名 | セキュリティ | 推奨用途 |
|---|---|---|---|
| P-256 | prime256v1 |
128 bit | 標準・推奨。互換性最高 |
| P-384 | secp384r1 |
192 bit | 高セキュリティ要件 |
| P-521 | secp521r1 |
256 bit | 最高強度（特殊用途） |
迷ったら P-256（prime256v1）を選んでください。互換性・速度・セキュリティのバランスが最も良い標準曲線です。
🔍 ハイブリッド運用（ECC + RSA デュアル証明書）
古い環境への互換性も維持しつつ、モダン環境では ECC の恩恵を受けたい場合、ECC と RSA の両方の証明書を同一サーバに設定する運用も可能です。クライアントの対応状況に応じて自動的に最適な証明書が選ばれます。
# Nginx の例：ECC と RSA の証明書を両方設定
ssl_certificate /path/to/ecc-fullchain.pem;
ssl_certificate_key /path/to/ecc-private.key;
ssl_certificate /path/to/rsa-fullchain.pem;
ssl_certificate_key /path/to/rsa-private.key;大規模サービスではこの方式で「新旧両対応 + 高速化」を実現している例が多数あります。
💡 よくある質問
Q. 既存の RSA 証明書から ECC に乗り換えるべき？
急ぐ必要はありません。次回更新タイミングで切り替えるのが現実的です。ACME 自動更新を併用すれば、世代交代がスムーズに進みます。
Q. ECC 証明書は SEO に影響しますか？
直接の影響はありませんが、ハンドシェイクが高速化することでサイト表示速度が向上し、結果的に Core Web Vitals の改善 → SEO 評価向上につながる可能性があります。
Q. ワイルドカード証明書も ECC で取得できますか？
はい、ECC でのワイルドカード証明書発行に対応しています。CSR 作成時に ECC 鍵を指定してください。
Q. ECC 証明書の価格は RSA と違いますか？
当店および FujiSSL では、ECC / RSA で価格差はありません。価格一覧をご参照ください。
📚 関連ページ
- CSR 生成ツール — ブラウザから簡単に CSR を作成
- 中間証明書とは — 証明書チェーンの仕組み
- 認証別の証明書の選び方 — DV / OV / EV の違い