2026年9月27日

WordPressのローカル開発環境でHTTPS証明書エラーを解消する方法

エラー・白い画面

ローカルのWordPressで「この接続ではプライバシーが保護されません」などの証明書エラーが出る原因の多くは、自己署名証明書をブラウザやOSが信頼していないことです。ローカル用の認証局（CA）を作って信頼させる mkcert を使えば、警告なしで https:// を開けるようになります。この記事では、エラー表示から原因を読み取る方法、よくある順に原因と確認・対処、ブラウザ以外（PHP側のループバック通信）で起きるエラーの直し方まで説明します。

まずエラー表示から原因を絞り込む

ブラウザの警告画面にはエラーコードが小さく表示されています。コードを見ると、どこを直せばよいかがかなり絞れます。

NET::ERR_CERT_AUTHORITY_INVALID（Chrome / Edge）、SEC_ERROR_UNKNOWN_ISSUER（Firefox）: 証明書の発行元を信頼していない。自己署名証明書でよく出ます。
NET::ERR_CERT_COMMON_NAME_INVALID: 証明書に書かれた名前とアクセスしたホスト名が一致しない。
NET::ERR_CERT_DATE_INVALID: 有効期限切れ、またはPCの時計がずれている。
「HSTS」に関する説明があり、例外として進むボタンが出ない: ドメインがHSTSの対象になっている。

証明書の中身は、ブラウザのアドレスバー左のアイコンから証明書ビューアーで見られます。コマンドで確認するなら、次のように実行します（example.test は自分のローカルドメインに置き換えます）。

openssl s_client -connect example.test:443 -servername example.test </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

-ext オプションは OpenSSL 1.1.1 以降で使えます。発行者（issuer）、有効期間、Subject Alternative Name（SAN）に並ぶホスト名を確認してください。

原因1: 自己署名証明書を信頼していない（最も多い）

自分で作った証明書は、どの認証局にも署名されていないため、ブラウザは偽物と区別できません。「詳細設定」から無理に進むこともできますが、毎回警告が出るうえ、Service Worker や一部のブラウザAPIが使えないなど、本番と挙動が変わります。

対処として、mkcert でローカル専用の認証局を作り、OSとブラウザに登録します。

# ローカル認証局を作成し、OS（と対応ブラウザ）の信頼ストアに登録
mkcert -install

# 使うホスト名をまとめて指定して証明書を発行
mkcert example.test localhost 127.0.0.1 ::1

カレントディレクトリに証明書と秘密鍵の2ファイルができます（ファイル名は指定した名前の数で example.test+3.pem のように変わります）。Webサーバーにこの2つを設定します。nginx の例です。

server {
    listen 443 ssl;
    server_name example.test;

    ssl_certificate     /path/to/example.test+3.pem;
    ssl_certificate_key /path/to/example.test+3-key.pem;

    root /var/www/example.test;
    # 以降は通常の WordPress 用設定
}

設定後はWebサーバーを再起動し、ブラウザも一度すべてのウィンドウを閉じて開き直します。Firefox は OS とは別の証明書ストアを使うため、mkcert が Firefox 用の登録に必要なツール（NSS の certutil）を見つけられないと、Firefox だけ警告が残ります。mkcert -install の出力に注意書きが出ていないか確認してください。

mkcert が作る認証局の秘密鍵（mkcert -CAROOT で場所が分かります）は、そのPCで信頼されるどんな証明書でも作れてしまう鍵です。他人に渡したり、リポジトリにコミットしたりしないでください。

原因2: 証明書の名前とホスト名が一致しない

example.test 用の証明書で www.example.test や localhost:8443 を開くと名前が一致しません。最近のブラウザは Common Name ではなく SAN の欄だけを見るため、古い手順で SAN なしの証明書を作った場合もこのエラーになります。

対処は、実際にアクセスするホスト名をすべて含めて証明書を作り直すことです。WordPress の「サイトアドレス（URL）」と証明書の名前が一致しているかも合わせて確認します。

wp option get home
wp option get siteurl

原因3: ドメインの選び方（.dev / .app / .local）

.dev と .app はトップレベルドメイン全体がブラウザのHSTSプリロードリストに入っており、HTTPSでしか開けず、警告画面から先へ進む選択肢も出ません。.local は macOS などで mDNS（Bonjour）と衝突し、名前解決が遅くなることがあります。

ローカル開発には、テスト用に予約されている .test、またはループバック用の .localhost を使うのが無難です。ドメインを変えたら hosts ファイル、Webサーバー、証明書、WordPress のURL設定をそろえて変更します。

原因4: 証明書を信頼させた場所と、ブラウザの場所が違う

Docker や WSL2 を使う構成では、「証明書を作って信頼させた環境」と「ブラウザが動いている環境」が別になりがちです。たとえば WSL2 の中で mkcert -install を実行しても、Windows 側の Chrome はその認証局を知りません。

ブラウザが動いているOS側で mkcert -install を実行し、発行した証明書ファイルをコンテナやWSL側のWebサーバーにマウント（コピー）する形にします。DDEV のように内部で mkcert を使うツールもあり、各ツールのドキュメントに手順があります。Local などのGUIツールにも証明書を信頼させる操作が用意されていますが、項目名はバージョンで変わるため（2026年10月現在）、各ツールのドキュメントで確認してください。

原因5: ブラウザは平気なのに、WordPress内部の通信がエラーになる

ブラウザでは鍵マークが出ていても、管理画面の「サイトヘルス」で「ループバックリクエストが失敗」「REST API で予期しない結果」と表示されることがあります。エラーに cURL error 60: SSL certificate problem: unable to get local issuer certificate とあれば、PHP 側がローカル認証局を信頼していないのが原因です。

WordPress の HTTP API（wp_remote_get() など）は、OS の信頼ストアではなく wp-includes/certificates/ca-bundle.crt を既定で使います。そのため mkcert の認証局を OS に入れても、PHP からの通信には効きません。

ローカル環境に限って、WordPress 同梱の CA バンドルに mkcert のルート証明書を足したファイルを作り、それを使わせます。

# CA バンドルの複製に mkcert のルート証明書を追記（パスは環境に合わせる）
cat /var/www/example.test/wp-includes/certificates/ca-bundle.crt \
    "$(mkcert -CAROOT)/rootCA.pem" > /var/www/certs/local-ca-bundle.crt

<?php
// mu-plugin 例: wp-content/mu-plugins/local-ca-bundle.php
add_filter( 'http_request_args', function ( $args ) {
	if ( 'local' !== wp_get_environment_type() ) {
		return $args;
	}
	$bundle = '/var/www/certs/local-ca-bundle.crt';
	if ( is_readable( $bundle ) ) {
		$args['sslcertificates'] = $bundle;
	}
	return $args;
} );

wp_get_environment_type() は wp-config.php で define( 'WP_ENVIRONMENT_TYPE', 'local' ); と設定したときに local を返します。証明書の検証そのものを止める sslverify => false を全体に設定する方法も見かけますが、本番に持ち込まれると通信の安全性が失われるため避けてください。

原因6: リバースプロキシ配下でHTTPSと認識されない

Docker の前段に nginx や Traefik を置き、プロキシで HTTPS を終端している構成では、WordPress から見ると HTTP でアクセスされているため、リダイレクトのループや、CSS が読み込まれない（混在コンテンツ）症状が出ます。プロキシが X-Forwarded-Proto ヘッダーを送っていることを確かめたうえで、wp-config.php の require_once ABSPATH . 'wp-settings.php'; より前に次を追記します。

<?php
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

このヘッダーは信頼できるプロキシからだけ届く構成で使ってください。

http から https に切り替えたときの後片付け

本文中の画像URLなどが http:// のまま残っていると混在コンテンツになります。データベースをバックアップしてから、WP-CLI で置き換えます。まず --dry-run で件数を確認します。

wp db export before-https.sql
wp search-replace 'http://example.test' 'https://example.test' --dry-run
wp search-replace 'http://example.test' 'https://example.test'

それでも以前の設定が残る場合は、ブラウザがHSTSやリダイレクトを記憶していることがあります。Chrome なら chrome://net-internals/#hsts で該当ドメインを削除し、キャッシュを消してから再度開きます。

まとめ

エラーコードを見て「発行元を信頼していない」「名前が違う」「期限」「HSTS」のどれかを先に切り分ける
自己署名証明書はやめ、mkcert のローカル認証局をブラウザが動くOS側で信頼させる
ドメインは .test か .localhost を使い、証明書・hosts・WordPress のURLをそろえる
サイトヘルスの cURL error 60 は PHP 側の問題。ローカル環境限定で CA バンドルを差し替え、検証の無効化は避ける
プロキシ構成では X-Forwarded-Proto を見て HTTPS と認識させ、URLの置き換えはバックアップ後に行う