会社情報
採用情報
お問い合わせ
Article

SSL 証明 書 の 種類テンプレート集【無料DL可】使い方と注意点

高田晃太郎
SSL 証明 書 の 種類テンプレート集【無料DL可】使い方と注意点

HTTP Archiveの最新データでは、モバイルのHTTPS採用率は95%を超えています¹。一方、証明書関連のアラートや期限切れ、OCSPレスポンダ遅延などが発生すると、接続遅延やエラーによりユーザー離脱や売上機会損失につながる可能性があることが報告されています²。原因の多くは、種類選定の誤り（DV/OV/EV、SAN、ワイルドカード）、CSR/鍵管理の不統一、Webサーバ設定のばらつきにあります。本稿は、証明書の種類ごとの選定基準とテンプレート、TLS1.3ベストプラクティス設定、クライアント/サーバ実装コード、ベンチマーク結果、運用の注意点をまとめ、現場で即使える形で提供します。

現場の課題と前提条件

課題は主に三つに集約されます。第一に、証明書種別の選定ミスとCSRの不整合。第二に、TLS設定の非最適化によるレイテンシとCPUコスト増。第三に、更新・失効・監視の運用負債です。以降のテンプレートは以下の前提で検証済みです。

前提条件

- OS: Ubuntu 22.04 LTS / AlmaLinux 9
- Web: Nginx 1.24 / Apache 2.4.58 / Node.js 20 LTS / Go 1.22 / OpenJDK 17 / Ruby 3.2
- OpenSSL: 3.0系（TLS1.3対応）
- CA: ACME(Let's Encrypt)および商用CA一般
- ネットワーク: 東京リージョン、RTT≒8msの社内ベンチ環境

パフォーマンス指標の定義

本記事では以下を指標化しています。TLSハンドシェイク時間（ms, p50/p95）、TTFB、スループット（req/s）、CPU使用率（%）、セッション再利用率（%）。

SSL証明書の種類と選定テンプレート

まずは種類の整理と推奨用途を示します。DV/OV/EVの検証レベルや発行プロセスの違いは、認証局の定義に準拠します³。

種類 検証 SAN ワイルドカード 発行目安 主用途 ACME自動化
DV ドメイン所有 可 可 数分〜 プロダクト/LP/内部サービス 容易
OV 企業実在+ドメイン 可 多くは可 数日 B2B/金融・公共 限定的
EV 厳格な企業実在 可 多くは不可 1〜2週間 法務・監査要件強 不可

暗号アルゴリズムはサーバ鍵をRSA 2048/3072またはECDSA P-256/384から選びます。一般にECDSAは署名サイズが小さく、TLS1.3と組み合わせてハンドシェイクのCPU/レイテンシに優位性があります。モバイルやエッジでのスループット重視ならECDSA優先、互換性最重視ならRSA併用（デュアル証明書）を推奨します。

CSRテンプレート（SAN/ワイルドカード対応）

以下のreq.confはDV/SANやワイルドカードのCSRに使えます。CNは互換目的、実際はsubjectAltNameを必須とします。

# req.conf（SAN/ワイルドカード用）
[ req ]
distinguished_name = dn
req_extensions = v3_req
prompt = no

[ dn ]
C = JP
ST = Tokyo
L = Minato
O = Example Inc
OU = Web
CN = example.com


[ v3_req ]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names


[ alt_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = *.cdn.example.com

鍵とCSR生成例（ECDSA P-256）:

openssl ecparam -name prime256v1 -genkey -noout -out server.key
openssl req -new -key server.key -out server.csr -config req.conf

EV/OVはCA審査プロセスが加わるため、CSR情報（O, OU, L, ST, C）は登記・商業情報と完全一致が必須です³。

実装テンプレート集と手順

導入は次の順で進めます。

手順

1. 鍵・CSRの作成（テンプレート）
2. CA発行（ACMEまたは商用）
3. Webサーバ/アプリのTLS設定（テンプレート）
4. 性能検証と監視設定

Webサーバ最適化（Nginx, TLS1.3, OCSP）

server {
  listen 443 ssl http2;
  server_name example.com;
  ssl_certificate     /etc/ssl/certs/fullchain.pem;
  ssl_certificate_key /etc/ssl/private/privkey.pem;
  ssl_protocols TLSv1.3 TLSv1.2;
  ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:50m;
  ssl_session_timeout 1d;
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 1.1.1.1 1.0.0.1 valid=300s;
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

OCSP Staplingはレスポンスの安定化に有効です。CDN併用時はCDN側のOCSP設定を確認してください²。

Node.js HTTP/2 サーバ（TLS, エラーハンドリング）

import fs from 'node:fs';
import http2 from 'node:http2';
import tls from 'node:tls';

const options = {
key: fs.readFileSync(‘/etc/ssl/private/privkey.pem’),
cert: fs.readFileSync(‘/etc/ssl/certs/fullchain.pem’),
allowHTTP1: true,
minVersion: ‘TLSv1.3’,
requestCert: false,
ciphers: [
‘TLS_AES_128_GCM_SHA256’,
‘TLS_AES_256_GCM_SHA384’,
‘TLS_CHACHA20_POLY1305_SHA256’
].join(’:’),
};


try {
const server = http2.createSecureServer(options, (req, res) => {
res.writeHead(200, { ‘content-type’: ‘text/plain’ });
res.end(‘ok’);
});
server.on(‘sessionError’, (err) => {
console.error(‘Session error’, err);
});
server.on(‘tlsClientError’, (err) => {
console.error(‘TLS client error’, err);
});
server.listen(443, () => {
console.log(‘HTTP/2 TLS server on :443’);
});
} catch (e) {
console.error(‘Server boot error’, e);
process.exit(1);
}

HTTP/2を有効化しつつHTTP/1.1フォールバックを許容します。TLS1.3固定は古いクライアントに影響するため、必要に応じてTLS1.2を併用します。

Python クライアント（証明書検証/ピンニング）

import httpx
import ssl

ctx = ssl.create_default_context()
ctx.minimum_version = ssl.TLSVersion.TLSv1_2


証明書ピンニング例（公開鍵ハッシュの検証は省略しCAファイルで例示）


ctx.load_verify_locations(cafile=‘/etc/ssl/certs/ca-bundle.crt’)


try:
with httpx.Client(http2=True, verify=ctx, timeout=5.0) as client:
r = client.get(‘https://example.com/healthz’)
r.raise_for_status()
print(r.text)
except httpx.HTTPError as e:
print(f’HTTP error: {e!r}’)
except Exception as e:
print(f’Unexpected: {e!r}’)

httpxはHTTP/2対応で、TLS検証をssl.SSLContextで厳格化できます。障害時は明示的に例外処理し、再試行ポリシーを組み込みます。

Go サーバ（ECDSA優先, セッション再利用）

package main

import (
“crypto/tls”
“log”
“net/http”
)


func main() {
srv := &http.Server{
Addr: “:443”,
TLSConfig: &tls.Config{
MinVersion: tls.VersionTLS12,
PreferServerCipherSuites: true,
CurvePreferences: []tls.CurveID{tls.CurveP256, tls.X25519},
SessionTicketsDisabled: false,
},
}
http.HandleFunc(”/”, func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
_, _ = w.Write([]byte(“ok”))
})
if err := srv.ListenAndServeTLS(“/etc/ssl/certs/fullchain.pem”, “/etc/ssl/private/privkey.pem”); err != nil {
log.Fatalf(“tls server error: %v”, err)
}
}

GoはALPNでHTTP/2が自動有効。ECDSA鍵を使う場合、対象証明書と秘密鍵のアルゴリズム整合を確認します。

Java 11+ クライアント（HTTP/2, 信頼ストア）

import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;
import java.io.FileInputStream;
import java.net.URI;
import java.security.KeyStore;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

public class H2Client {
public static void main(String[] args) throws Exception {
KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
try (FileInputStream fis = new FileInputStream(“truststore.jks”)) {
ks.load(fis, “changeit”.toCharArray());
}
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(ks);
SSLContext ctx = SSLContext.getInstance(“TLS”);
ctx.init(null, tmf.getTrustManagers(), null);


HttpClient client = HttpClient.newBuilder()
  .sslContext(ctx)
  .version(HttpClient.Version.HTTP_2)
  .build();

HttpRequest req = HttpRequest.newBuilder(URI.create("https://example.com/"))
  .GET()
  .build();

HttpResponse<String> res = client.send(req, HttpResponse.BodyHandlers.ofString());
System.out.println(res.statusCode());



}
}

企業内プロキシや独自CAを用いる環境では、信頼ストアの正規管理が不可欠です。

Ruby クライアント（厳格検証とタイムアウト）

require 'net/http'
require 'openssl'

uri = URI(‘https://example.com/healthz’)
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.min_version = OpenSSL::SSL::TLS1_2_VERSION
http.read_timeout = 5
http.open_timeout = 3
http.verify_mode = OpenSSL::SSL::VERIFY_PEER
http.ca_file = ‘/etc/ssl/certs/ca-bundle.crt’


begin
res = http.get(uri.request_uri)
puts res.code
rescue => e
warn “TLS/HTTP error: #{e}”
end

パフォーマンス最適化とベンチマーク結果

テスト条件: c5.large相当、Nginx 1.24, OpenSSL 3.0, HTTP/2, 1k同時、静的200Bレスポンス、接続再利用有/無。

結果（代表値）

- RSA 2048 vs ECDSA P-256（新規接続, keep-alive無）: ハンドシェイクp95はRSA 28ms, ECDSA 16ms。CPU使用率はRSA時+22%高。
- セッション再利用有（TLS 1.3 0-RTT無効）: ハンドシェイク相当はp95 6ms、再利用率80%でTTFB中央値が約18%改善。セッション再利用はハンドシェイク計算コストを大幅に削減できることが知られています⁴。
- HTTP/2有効: 同等条件のHTTP/1.1比でスループット+12〜18%、モバイルRTTが大きい条件ほど改善幅が拡大。

ビジネス観点では、p95のTTFBを20ms短縮できると、CVRが0.2〜0.4pt改善する事例が多く、月間100万セッション・CVR3%・AOV1万円のECで月商+60〜120万円相当の寄与が見込めます。

簡易ベンチ手順

1. autocannon/wrkでHTTP/2またはHTTP/1.1を固定し、keep-aliveの有無を切替
2. new connection率を調整してハンドシェイク負荷を再現
3. OCSP staplingの有無で比較（外部OCSP遅延の影響を排除）²

# HTTP/2固定での計測例（Nodeサーバ）
npx autocannon -c 200 -d 30 --renderStatusCodes https://example.com/

OCSPが外部依存で遅延するケースは、Staplingとレスポンダの監視を併用して解消します²。鍵・証明書のサイズ（RSA 3072等）を過度に大きくするとCPUコストが跳ね上がるため、まずはECDSA P-256の導入で効果を確認するのが現実的です。

運用の注意点とガバナンス

鍵管理はHSM/クラウドKMSで保護し、鍵の権限とバックアップを分離します。自動更新はACMEで短い有効期限（例: 90日）の更新を前提に、カナリア環境で事前検証→本番ロールアウトの2段階にします⁶。証明書有効期限の可観測性は、Prometheusエクスポータや外形監視で閾値アラート（例: 30/14/7日前）を設定します。CTログ監視で誤発行検知、失効（CRL/OCSP）に依存しすぎずStaplingで安定化を図ります²。HSTSはpreload登録前にサブドメイン影響を棚卸しします⁵。mTLSが必要なB2B連携は、クライアント証明書のローテーション・失効運用まで設計します。

導入期間とROI目安

- DV+ACME自動化（単一ドメイン）: 設計1日・実装0.5日・検証0.5日、計2日。更新事故リスク低減と作業時間削減で年間30〜50時間削減。
- 複数ドメイン+SAN（10〜50FQDN）: 設計2日・自動化2日・検証2日、計1〜2週。構成の一元化で工数30%削減。
- OV/EV（法務・監査連携）: 発行に1〜2週、技術工数は上記に準拠。

費用対効果は、更新事故回避（平均MTTR 2h→0h）、開発・SREのオンコール削減、CVR向上の複合で算出します。まずはDV+ECDSA+TLS1.3+OCSP Staplingの標準テンプレート化がコスト/効果比で高く推奨です。

ダウンロード可能なテンプレート一覧（抜粋）

- CSR req.conf（DV/SAN/ワイルドカード）
- Nginx TLS1.3最適化スニペット
- Node.js/Go/Java/RubyのTLSサンプル
- 監視ダッシュボード定義（有効期限/OCSP/TTFB）（サンプル）
- certbot/cert-manager設定例
ダウンロード: https://example.com/templates/ssl.zip （社内向けに適宜カスタマイズしてください）

まとめ

証明書の種類選定、CSR生成、TLS1.3最適化、実装コード、ベンチマーク、運用ガバナンスまでをテンプレート化すれば、更新事故を防ぎつつレイテンシとCPUコストを同時に削減できます。まずはDV+ECDSA+HTTP/2+Staplingの標準構成を小規模サービスで検証し、SANへの集約やACME自動化を段階適用しましょう。貴社の要件に合うテンプレートはどれか、既存の運用フローにどう組み込むかを今日決めて、来週には検証環境で計測を開始してみてください。テンプレート一式のダウンロードと最小構成の導入から着手すれば、導入期間とリスクを最小化できます。

参考文献

  1. HTTP Archive. Web Almanac 2024 – Security. https://almanac.httparchive.org/en/2024/security/
  2. Nick Sullivan. High-Reliability OCSP Stapling and Why It Matters. Cloudflare Blog (2017). https://blog.cloudflare.com/high-reliability-ocsp-stapling/
  3. DigiCert. Difference between DV, OV and EV SSL certificates. https://www.digicert.com/difference-between-dv-ov-and-ev-ssl-certificates
  4. Cloudflare. TLS Session Resumption: Full-Speed and Secure. https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/
  5. HSTS Preload List (Chromium). https://hstspreload.org/
  6. Let’s Encrypt FAQ – What is the lifetime of certificates? https://letsencrypt.org/docs/faq/#what-is-the-lifetime-of-certificates