はじめに

前回、ローカルでの HTTPS テスト環境の構築について、お話をしました。

この環境では、HTTPS のテスト環境を 1 台のパソコンの中だけで、実現することができます。

しかし、これは、開発において非常に便利な利点ではありますが、このままでは、チーム開発や、モバイル端末のテストなどに対応できないという欠点も持っています。

それに、もし、テスト環境を 1 台のパソコンの中だけで実現したいだけであれば、HTTPS サーバーを立ち上げるまでもなく、 localhost を使うだけで事足ります。

localhost は特別なホストとして扱われ、http://localhost や http://127.0.0.1 は HTTPS ではなくても Secure Context として扱われます。そのため、Secure Context を必要とする Web API のテストでは、HTTPS を用意しなくても利用できる場合があります。

そこで、今回は、この環境を拡張してローカルな環境（プライベートネットワーク）内で、モバイル端末などの外部端末から HTTPS のテスト環境へアクセスする方法について記していきたいと思います。

※ ここでいう「外部端末」とは、インターネット上の端末ではなく、HTTPSサーバーを実行しているPCとは別の端末を指します。

想定しているテスト環境のイメージ

今回の説明で想定している環境のイメージを下記に示します。

スマホのブラウザ画面から、同じプライベートネットワーク内のパソコンで実行されている HTTPS サーバーにアクセスし、動作確認を行えるイメージです。

（図１）プライベートネットワーク LAN イメージ 
┌────────────────────────────────┐               ┌──────┐
│                                │               │  ス  │
│             ┌────────────────┐ │               │  マ  │
│             │                │ │               │  ホ  │
│             │ HTTPS サーバー  │ │               │      │
│             │                │ │               └──────┘
│             │ ポート：3000    │ │                  /
│             │                │ │                 /＿＿
│             │                │ │　　　　　　　　　　　/
│             │                │ │                   /
│             │                │ │           ┌───────────────┐
│             │                │ │           │ Wi-Fi ルーター │
│             └────────────────┘ │           │               │
└────────────────────────────────┘           └───────────────┘
　　　　　　　　　│ 192.168.10.108                     │ 192.168.10.1
────────────────────────────────────────────────────────────────
                　プライベートネットワーク（ LAN ）　　　　

パソコンと Wi-Fi ルーター間は、図では有線 LAN での接続を想定していますが、同じプライベートネットワークに接続され、端末間の通信が許可されていれば、スマホとパソコンのどちらも無線 LAN 接続で構いません。

図上では、IP アドレスを明確に固定していますが、当然このアドレスである必要はなく、説明の便宜上の仮設定です。

HTTPS サーバーは、PCのLAN側IPアドレス（192.168.10.108）を使用して、プライベートネットワーク内の端末からアクセスできるようになります。

多くの場合、プライベートネットワーク内の IP アドレスは、DHCP サーバーによって自動的に割り当てられます。HTTPS サーバーを実行するパソコンの IP アドレスが変更される可能性がある場合は、固定化しておく方が便利です。

そうすれば、後に説明する、証明書の作り直しの頻度や手間も減ることになります。

テスト環境の拡張

環境の拡張では、以下の作業を行う必要があります。

  1. LAN 内で使用するIPアドレスを含めた HTTPS 証明書の再作成
  2. 再作成した証明書で HTTPS サーバーの再立ち上げ
  3. ルート認証局（CA）の証明書の取得
  4. ルート認証局（CA）の証明書のスマホへの転送と登録

今回の説明では、外部端末としてスマホを想定しています。他の端末であっても基本的な作業は同じですが、各端末でのルート認証局（CA）証明書の登録方法が異なります。

それでは、順番に詳しくみていきたいと思います。

1. LAN 内で使用するIPアドレスを含めた HTTPS 証明書の再作成

外部端末から HTTPS で接続するためには、HTTPS 証明書にアクセス先の IP アドレスまたはホスト名を含める必要があります。

mkcert localhost 127.0.0.1 192.168.10.108 ::1

👉 このコマンドを実行すると下記のファイルが作成されます。

  • localhost+3-key.pem
  • localhost+3.pem

ここで、お察しの良い方は、もうお気づきだと思いますが、HTTPS 証明書に、LAN 内で使用するIPアドレスを含めるということは、IP アドレスが変更になるたびに作り直さないといけないということです。

前述で、プライベートネットワークとの接続に使用する IP アドレスの固定化をすすめたのは、これが理由です。IP アドレスが固定化されていれば、この作業を1度だけ行えばよく、それ以降は行う必要がなくなるからです。

もし、DNS や mDNS などによって名前解決ができるのであれば、LAN 内で使用する IP アドレスの代わりに、ホスト名を HTTPS 証明書に含めることも可能です。

例：

外部端末から、HTTPS サーバーを起動しているパソコンに、konkitsune.local でアクセス可能な場合

mkcert localhost 127.0.0.1 konkitsune.local ::1

2. 再作成した証明書で HTTPS サーバーの再立ち上げ

再作成した HTTPS 証明書を読み込めるようにして、 HTTPS サーバーの再立ち上げを行います。

server.js の下記の部分を、再作成した HTTPS 証明書を指定するようにします。

        :
// HTTPS サーバー起動
https.createServer(
  {
👉  key: fs.readFileSync("localhost+3-key.pem"),
👉  cert: fs.readFileSync("localhost+3.pem")
  },
        :

再立ち上げすると、HTTPS サーバーは、プライベートネットワーク上の端末からアクセスできる状態になります。

実際に、スマホから 192.168.10.108 にアクセスすると、下記のような応答画面が表示されることを確認できます。


（図２）iPhone警告画面


この画面は、スマホのブラウザが表示している警告です。HTTPS 証明書を信頼できる認証局まで検証できないため、このような警告が表示されます。

ここで、画面下部の「詳細設定」をタップすると、新たな警告画面が表示されます。


（図３）iPhone警告画面続き


ここでもめげずに、画面中ほどの「192.168.10.108にアクセスする（安全ではありません）」をタップして、先にすすめるとサイトのトップ画面が、警告表示付きで表示されます。

警告表示はブラウザにより異なりますが、今回の環境では URL 欄に黒字に「×」で表示されています。


（図４）iPhone警告付きサイト画面


このままでは、HTTPS暗号化そのものは成立していても、証明書の信頼性を確認できないため、通信相手が正当なサーバーであることを保証できません。

そのため、開発用のプライベートネットワークで「HTTPSで接続できるか」を確認するだけなら、警告を了承してテストすることもできます。

ただし、これは証明書の信頼性を確認できない状態を意図的に許容するものなので、開発・検証用途に限定してください。

3. ルート認証局（CA）の証明書の取得

ルート認証局（CA）をスマホに登録するためには、まず、 ルート認証局（CA）証明書を取得する必要があります。

ルート認証局（CA）証明書の格納箇所は下記のコマンドで知ることができます。

mkcert -CAROOT

実行すると、下記のように証明書の格納フォルダーが表示されます。

C:\Users\ユーザー名\AppData\Local\mkcert

このディレクト配下には、下記の２つのファイルが格納されています。

rootCA.pem
rootCA-key.pem

rootCA.pem　が、ルート認証局（CA）証明書となります。

このルート認証局（CA）証明書をアクセスを行いたい端末に登録することで、HTTPS サーバーへのアクセス時に表示される警告画面を抑制することが可能となります。

※ rootCA-key.pem は、新しい「信頼される証明書」を発行できる秘密鍵です。誤ってスマホなどの外部端末に渡さないように注意してください。

4. ルート認証局（CA）の証明書のスマホへの転送と登録

ルート認証局（CA）の証明書は、ファイルなので様々な方法で、スマホなどの外部端末に転送することが可能です。

例えば、

  • メール
  • USBメモリ
  • NAS
  • ダウンロード

など。

やりやすい方式での転送で問題ありません。

スマホなどの外部端末でのルート認証局（CA）の証明書の登録は、端末によりその作業が異なります。各端末の仕様にそった登録を行う必要があります。

例えば、スマホ（ iPhone iOS26 ）における登録方法は、

  • ファイルアプリを開き、転送した rootCA.pem が格納されているフォルダを開く
  • rootCA.pem　をタップして開く
  • 構成プロファイルとしてインストール
  • 設定アプリを開き、一般 → 情報 → 証明書信頼設定に遷移する
  • 「ルート証明書を全面的に信頼」に表示されている該当ルート証明書のスイッチを有効化

という流れになります。

証明書が複数表示されている場合は、証明書の名前や詳細情報を確認し、今回インストールしたmkcertのルートCAであることを確認してください。

※ mkcertの公式説明でも、iOSではCAをインストールした後に「Full Trust」を有効にする必要があるとされています。

ここまでが、完了するとスマホから 192.168.10.108 にアクセスしても、警告画面が表示されなくなります。


（図５）サイト画面


※ 筆者の環境では、ルート認証局（CA）の証明書をダウンロードするために使用したタブでリロードを行っても、しばらく警告表示が消えませんでした。新しいタブを開いてアクセスしたところ、警告表示はなくなりました。原因については確認できていません。

◇ URL 欄の警告表示が消えない場合

ルートCAを登録して信頼しても、URL欄の警告表示が消えない場合があります。

例えば、

mkcert localhost 127.0.0.1 konkitsune.local ::1

で、HTTPS 証明書を作成している状態で、ブラウザから

https://192.168.10.108:3000/

で、アクセスした場合には、消えず出続けることがあります。

ブラウザは、アクセス先のホスト名やIPアドレスと、HTTPS証明書の SAN（ Subject Alternative Name ）に記載された名前が一致しているかを確認します。そのため、konkitsune.local を証明書に含めていても、192.168.10.108 でアクセスした場合、192.168.10.108 が証明書に含まれていなければ、ホスト名不一致による警告が発生します。

運用上、どちらを使うか統一するか、統一が難しいのであれば、 HTTPS 証明書に両方を含ませてつくるというのも手段です。

例：

mkcert localhost 127.0.0.1 konkitsune.local 192.168.10.108 ::1

次回予告

次回は、実際にこの拡張作業を行い、スマホ（ iPhone iOS26 ）に、サイトの画面が表示されることを確認していきたいと思います。