2026年9月16日

OpenSSLで自己署名証明書を作成する方法｜WordPressの開発環境をHTTPS化する手順と注意点

サーバーセキュリティ・SSL

OpenSSLで自己署名証明書を作るなら、ブラウザに受け入れられるために SAN（subjectAltName）にドメイン名を入れる ことが最重要です。1台の開発用サーバーなら1行のコマンドで作れますが、複数の開発サイトを扱うなら「自分専用の認証局（ローカルCA）を作り、そこでサーバー証明書に署名する」方法のほうが、警告を出さずに運用しやすくなります。この記事では、両方の作り方、Nginx/Apacheへの設定、OSへの信頼の追加、WordPressからの通信で起きやすいエラーへの対処までを解説します。

自己署名証明書は、開発環境や社内の検証環境で使うためのものです。一般公開するWordPressサイトでは、Let's Encryptなどの公的な認証局が発行した証明書を使ってください。

作業の前に決めておくこと

開発用のドメイン名

開発環境のドメインには、テスト用に予約されている .test を使うのが無難です（この記事では wp.test を例にします）。.dev は実在するトップレベルドメインで、ブラウザがHTTPSを強制する一覧（HSTSプリロード）に入っているため、開発用に使うと思わぬ挙動になります。.local はネットワーク内の機器を探す仕組み（mDNS）と衝突することがあるため、こちらも避けたほうが安全です。ドメインは hosts ファイルで開発用サーバーのIPアドレスに向けておきます。

OpenSSLのバージョン

openssl version

主要なLinuxディストリビューションやmacOSのHomebrew版では、OpenSSL 3系が広く使われています（2026年10月現在）。この記事のコマンドはOpenSSL 3系を前提にしています。秘密鍵を暗号化しない指定は、3系では -noenc が正式で、以前からの -nodes は非推奨ですが引き続き使えます。macOS標準の openssl はLibreSSLの場合があり、一部のオプションが使えないことがあります。

方法1: 1行で自己署名証明書を作る

開発用サーバーが1台だけで、ブラウザの警告を一度承認して使えればよい場合の方法です。

openssl req -x509 -newkey rsa:2048 -noenc -sha256 -days 365 \
  -keyout wp-test.key -out wp-test.crt \
  -subj "/CN=wp.test" \
  -addext "subjectAltName=DNS:wp.test,DNS:localhost,IP:127.0.0.1"

各オプションの意味は次の通りです。

-x509: 証明書署名要求（CSR）ではなく、自己署名の証明書を直接作る
-newkey rsa:2048: 新しいRSA鍵（2048ビット）を同時に作る。ECDSA鍵にしたい場合は -newkey ec -pkeyopt ec_paramgen_curve:prime256v1
-noenc: 秘密鍵をパスフレーズで暗号化しない（Webサーバーが起動時に入力を求めないようにするため）
-days 365: 有効期間
-subj: 証明書の名前（CN）を対話なしで指定
-addext "subjectAltName=...": ブラウザが実際に確認するドメイン名やIPアドレス

現在の主要なブラウザは、CNではなくSANに書かれた名前で証明書とドメインの一致を確認します。SANを入れ忘れると、自己署名を承認しても「名前が一致しない」というエラーが残ります。最もつまずきやすい点なので、作った後は次のコマンドで中身を確かめる習慣をつけておきます。

openssl x509 -in wp-test.crt -noout -subject -dates -ext subjectAltName

この方法で作った証明書は、ブラウザに「この接続は安全ではありません」と表示され、毎回またはブラウザごとに例外を承認する必要があります。証明書そのものをOSに信頼させることもできますが、サイトの数が増えると管理が煩雑になるため、次の方法2を勧めます。

方法2: ローカルCAを作ってサーバー証明書に署名する

1. ローカルCAを作る

openssl req -x509 -newkey rsa:3072 -noenc -sha256 -days 1825 \
  -keyout dev-ca.key -out dev-ca.crt \
  -subj "/CN=My Dev Local CA"

openssl req -x509 は、標準の設定ファイルでは認証局として使える印（basicConstraints の CA:TRUE）を付けます。念のため、openssl x509 -in dev-ca.crt -noout -text で CA:TRUE が含まれているかを確認します。設定ファイルはディストリビューションによって異なるためです。

2. サーバー用の鍵と署名要求を作る

openssl req -newkey rsa:2048 -noenc \
  -keyout wp-test.key -out wp-test.csr \
  -subj "/CN=wp.test"

3. 拡張情報を書いたファイルを用意して署名する

cat > wp-test.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:wp.test, DNS:localhost, IP:127.0.0.1
EOF

openssl x509 -req -in wp-test.csr \
  -CA dev-ca.crt -CAkey dev-ca.key -CAcreateserial \
  -out wp-test.crt -days 397 -sha256 -extfile wp-test.ext

署名要求に含めたSANは、openssl x509 -req では標準ではサーバー証明書に引き継がれません。そのため、SANなどの拡張情報は -extfile で署名の時点に指定します。ここが抜けて「SANの無い証明書」になる失敗がよくあります。

有効期間は短めにしておくのが無難です。Appleの製品は、OSが信頼する証明書のうちTLSサーバー証明書の有効期間に上限を設けており、長すぎる証明書は信頼されないことがあります。上限の扱いは変わることがあるため、1年程度にしておくと問題が起きにくくなります。extendedKeyUsage = serverAuth を入れているのも、一部の環境がこれを求めるためです。

4. 鍵の扱い

chmod 600 dev-ca.key wp-test.key
openssl verify -CAfile dev-ca.crt wp-test.crt

verify で OK と表示されれば、署名の関係は正しく作れています。

**ローカルCAの秘密鍵 dev-ca.key は厳重に管理してください。** このCAを信頼したパソコンでは、この鍵で署名された証明書はどのドメインのものでも正規のものとして扱われます。鍵が漏れると、そのパソコンへの通信を偽装される危険があります。Gitリポジトリに含めない、共有フォルダに置かない、不要になったら削除してOSからも信頼を外す、という扱いを徹底します。

Webサーバーに設定する

証明書と鍵は、Webサーバーの設定ファイルから読める場所（例: /etc/ssl/local/）に置きます。

# Nginx の例
server {
    listen 443 ssl;
    server_name wp.test;

    ssl_certificate     /etc/ssl/local/wp-test.crt;
    ssl_certificate_key /etc/ssl/local/wp-test.key;

    root /var/www/wordpress;
    # 以下、PHP-FPM などの設定
}

# Apache の例（mod_ssl を有効にしておく）
<VirtualHost *:443>
    ServerName wp.test
    DocumentRoot /var/www/wordpress

    SSLEngine on
    SSLCertificateFile    /etc/ssl/local/wp-test.crt
    SSLCertificateKeyFile /etc/ssl/local/wp-test.key
</VirtualHost>

設定を変えたら、nginx -t や apachectl configtest で構文を確認してから再読み込みします。サーバーが正しい証明書を返しているかは、openssl s_client -connect wp.test:443 -servername wp.test </dev/null で確認できます。

ブラウザで警告を出さないための信頼の追加

方法2で作った場合、ローカルCAの証明書（dev-ca.crt）を、開発に使うパソコンのOSに信頼させます。サーバー証明書ではなく、CAの証明書を登録する点に注意します。

Windows: 証明書ファイルを開き、「信頼されたルート証明機関」に保存する。管理者のコマンドプロンプトなら certutil -addstore -f ROOT dev-ca.crt
macOS: キーチェーンアクセスに追加し、「常に信頼」に設定する
Ubuntu/Debian: /usr/local/share/ca-certificates/ に拡張子 .crt で置き、sudo update-ca-certificates
RHEL系: /etc/pki/ca-trust/source/anchors/ に置き、sudo update-ca-trust

Firefoxは独自の証明書ストアを持っているため、OSに追加しても認識されない場合があります。その場合は、Firefoxの設定画面から証明書を読み込むか、OSの証明書を参照する設定を確認してください。画面の表記はOSやブラウザのバージョンで変わります。

WordPress側でつまずきやすい点

証明書を信頼させてもWordPressからの接続が失敗する

WordPressの外部通信（HTTP API）は、OSの証明書ストアではなく、WordPressに同梱されたCAの一覧（wp-includes/certificates/ca-bundle.crt）を標準で使います。そのため、サーバーのOSにローカルCAを登録しても、サイトヘルスのチェックやREST APIを使う処理で、サイト自身へのHTTPS接続が「cURL error 60」などの証明書エラーになることがあります。

開発環境だけで、サイト自身への通信にローカルCAを使わせるには、http_request_args フィルターで検証に使う証明書ファイルを指定できます。mu-pluginとして置く例です。

<?php
/**
 * wp-content/mu-plugins/local-dev-ca.php
 * 開発環境専用: サイト自身への HTTPS 通信の検証にローカルCAを使う
 */
if ( 'local' !== wp_get_environment_type() ) {
	return;
}

add_filter( 'http_request_args', function ( $args, $url ) {
	if ( 'wp.test' === wp_parse_url( $url, PHP_URL_HOST ) ) {
		$args['sslcertificates'] = '/etc/ssl/local/dev-ca.crt';
	}
	return $args;
}, 10, 2 );

wp-config.php に define( 'WP_ENVIRONMENT_TYPE', 'local' ); を設定した環境でだけ動くようにしています。対象を開発用ドメインに限っているので、外部への通信は通常通りWordPress同梱の一覧で検証されます。sslverify を false にして検証そのものを止める方法も見かけますが、通信の安全性を損なうため、本番に持ち込まないよう注意が必要です。

サイトのURLと混在コンテンツ

HTTPSに切り替えたら、「設定」→「一般」のWordPressアドレスとサイトアドレスを https:// に変更します。既存の投稿に http:// の画像URLが残っていると、混在コンテンツとしてブラウザに警告されます。データベースのURLを置き換える場合は、事前にバックアップを取り、WP-CLIの wp search-replace などシリアライズされたデータを壊さない方法を使います。

まとめ

自己署名証明書にはSAN（subjectAltName）を入れる。ブラウザはCNではなくSANで名前を確認する
1台なら openssl req -x509 の1行で作れる。複数サイトならローカルCAを作って署名する
openssl x509 -req で署名するときは、SANなどの拡張情報を -extfile で指定する
ローカルCAの秘密鍵は厳重に管理し、不要になったらOSの信頼から外す
WordPressの外部通信は同梱のCA一覧を使うため、開発環境だけ http_request_args で調整する
公開サイトでは自己署名ではなく、公的な認証局の証明書を使う