自己署名証明書をルート証明書として読み込んでみた

はじめに

自己署名証明書 (オレオレ証明書) を、ルート証明書としてインポートした場合の、ブラウザの挙動について調べた結果を報告します。

自己署名証明書によるSSL化では、ブラウザで自己署名を例外として受け入れても、アドレスバーに警告が残ります。この警告を消すために、自己署名証明書をルート証明書としてインポートする方法が、ネット上では紹介されています。これを試して見たところ、ブラウザによって挙動が異なることが分かりました。そこで主要なブラウザについて挙動を調べてみました。

最後に自己署名証明書の作成とインポートの手順についても記載しています。

ルート証明書としてインポートする手間をかけるのであれば、プライベート認証局を構築して、その認証局の証明書をルート証明書としてインポートするという選択肢も有ります。後述するように、自己署名証明書の場合は、Firefoxにルート証明書としてインポートできないという問題が有りますが、プライベート認証局の証明書の場合は、Firefoxにも問題なくインポートできます。

プライベート認証局によるWebサーバーのHTTPS化

プライベート認証局を構築して、Webサーバー向けのサーバー証明書を発行する手順について紹介します。認証局の証明書をWebブラウザやOSの証明書ストアに読み込むことで、自己署名証明書を使ったサーバーに、警告なしにアクセスすることができます。

pvision.jp

2023.05.02

テストケース

以下の4つのケースでテストしました。ルート証明書としてインポートする他に、従来通りブラウザで例外として受け入れた場合もテストしています。

• SAN – subjectAltNameにサーバーのFQDNを指定する
  SANは証明書に含めることのできるフィールドのひとつです。Chromeはこれを設定しないとエラーになるとの記述があったので試してみました。
• 例外受入 – ブラウザの警告画面で、例外を受け入れる (警告を無視してアクセス)
• インポート – ルート証明書としてインポートする

使用ソフトウェア

テストに使用したブラウザとApacheのバージョンです。Mac OSとWindows 11でテストしています。

Mac OS (Ventura)

• Safari 16.4
• Chrome 112.0.5615.45
• Edge 110.0.1661.62
• Firefox 111.0.1

Windows 11 Pro

• Chrome 111.0.5563.147
• Edge 111.0.1661.62
• Firefox 111.0.1

Web Server

• Apache 2.4

結果

テスト結果を下表に示します。MacとWindows環境で違いはなかったので、まとめてあります。

*1 – 例外を受け入れた後は警告を出ない。

*2 – 例外を受け入れた後もアドレスバーに警告が出される。
エラーコード: ERR_CERT_AUTHORITY_INVALID (ケース2)
エラーコード: ERR_CERT_COMMON_NAME_INVALID (ケース3)

*3 – 例外を受け入れた後もアドレスバーに警告が出される。
エラーコード: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

*4 – 「認証局の証明書でないため、認証局の一覧には追加できません。」と表示されて、ルート証明書としてインポートできない。

考察

全体

ルート証明書としてインポートできるのは、Chrome, Edge, Safariのみです。Firefoxはインポートできませんでした。

ルート証明書としてインポートする場合は、SANを含む証明書を作成する必要があります。SANの設定がないと、ブラウザによってはアドレスバーの警告が解消されないためです。

例外として受け入れる場合は、SANは必要ありません。ただしSANの有無に関わらず、アドレスバーの警告は残ります。

WindowsとMac OSで挙動に違いはありません。

ブラウザの挙動

Safari

例外として受け入れた場合、他のブラウザのような警告は出しません。ただし一度例外を受け入れると、削除する方法が不明です。(間違って受け入れた場合など、削除できないと困るはずですが …) 例外として受け入れると警告を出さないので、あえてルート証明書としてインポートする必要はなさそうです。

Chrome, Edge

SANを含めて証明書を作成し、ルート証明書としてインポートすることで、警告を消すことができます。

※ ChromeとEdgeは、Chromiumベースなので、基本的に同じ挙動のようです。

Firefox

認証局の証明書としてはインポートできませんでした。Safari, Chrome, EdgeがOSの証明書ストアを使っているのに対して、Firefoxは自前の証明書ストアを持っていて、その部分で他のブラウザとは動作が異なるようです。

例外の受け入れと削除 (解除) について

• 例外を受け入れると、Firefoxではサーバー証明書として証明書ストアに登録されます。Safari, Chrome, Edgeの場合、OSのキーストア/証明書ストアには登録されません。それぞれの持つローカルの証明書ストアに登録されると考えられますが、Firefoxと違って開示されていません。
• クライアントのOSを再起動しても例外は削除されません。
• 受け入れた例外の削除方法は、
  • Safariの場合、例外をブラウザ側で削除する方法は不明です。
  • Firefoxの場合、アドレスバーで「安全でない接続」をクリックし、「例外から削除」をクリックすると証明書ストアが開き例外を削除できます。
  • Chromeの場合、アドレスバーで「保護されていない通信」をクリックし、「警告をオンにする」をクリックすると例外が削除されます。また「警告をオンにする」が表示されない場合は、アドレスバーをクリックした時点で例外が削除されます。
  • Edgeの場合、アドレスバーで「セキュリティ保護なし」をクリックし、「警告を有効にする」をクリックすると例外が削除されます。また「警告を有効にする」が表示されない場合は、アドレスバーをクリックした時点で例外が削除されます。
  • Chrome, Edgeで「警告をオンにする」「警告を有効にする」が表示される場合とされない場合がありますが、何が機序になっているのか不明です。

ブラウザでのチェックについて

Chrome, Edgeの場合は、サーバー証明書に対して次のようなチェックがされているようです。

1. 第三者による署名がされているかどうか
2. サーバーのアドレスが正しく設定されているか

自己署名証明書を持つサーバーにアクセスした場合は、まず#1のチェックで警告が出ます。

ルート証明書としてインポートした場合は、#1のチェックはパスするようです。しかし#2のチェックでSANが設定されていないと警告が出るようです。

テストの実行手順

サーバー証明書の作成 (SAN有りの場合)

サーバー証明書をSAN (subjectAltName) と共に作成する方法を説明します。

まず秘密鍵 (web-server.key) を作成します。

openssl genpkey -out web-server.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048

次に署名要求 (web-server.csr) を作成します。署名要求にはsubjectAltNameを含めています。example.comは、証明書発行対象のサーバーのFQDN (Fully Qualified Domain Name) で適宜置き換えてください。

openssl req -new -key web-server.key -out web-server.csr -addext "subjectAltName=DNS:example.com"

DNS名ではなくIPアドレスを指定する場合は、次のように指定します。

subjectAltName=IP:aaa.bbb.ccc.ddd

下記の項目について質問されるので、適宜指定してください。

Country Name (2 letter code) [AU]: JP
State or Province Name (full name) [Some-State]: Tokyo
Locality Name (e.g. city) []: Chiyoda
Organization Name (eg. company) [Internet Widgits Pty Ltd]: Hoge LLC
Organiztion Unit Name (eg. section) []: Home
Common Name (e.g. server FQDN or YOUR name) []: example.com
Email Address [];

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

必須項目は、Country Name, Organization Name, Common Nameです。

Common Nameは、Webブラウザに入力されたアドレスと比較されます。WebサーバーがFQDNを持っている場合は、それを指定します。IPアドレスしか持たない場合は、IPアドレスを指定します。

A challenge passwordは設定しないでください。設定した場合は、Webサーバーの起動時に、パスワードの入力が必要になります。

署名要求に署名して、自己署名証明書 (web-server.crt) を作成します。

openssl x509 -in web-server.csr -out web-server.crt -req -signkey web-server.key -days 365 -copy_extensions copy

サーバー証明書の作成 (SAN無しの場合)

サーバー証明書を作成する方法を説明します。

まず秘密鍵 (web-server.key) を作成します。

openssl genpkey -out web-server.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048

次に署名要求 (web-server.csr) を作成します。

openssl req -new -key web-server.key -out web-server.csr

下記の項目について質問されるので、適宜指定してください。

Country Name (2 letter code) [AU]: JP
State or Province Name (full name) [Some-State]: Tokyo
Locality Name (e.g. city) []: Chiyoda
Organization Name (eg. company) [Internet Widgits Pty Ltd]: Hoge LLC
Organiztion Unit Name (eg. section) []: Home
Common Name (e.g. server FQDN or YOUR name) []: example.com
Email Address [];

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

必須項目は、Country Name, Organization Name, Common Nameです。

Common Nameは、Webブラウザに入力されたアドレスと比較されます。WebサーバーがFQDNを持っている場合は、それを指定します。IPアドレスしか持たない場合は、IPアドレスを指定します。

A challenge passwordは設定しないでください。設定した場合は、Webサーバーの起動時に、パスワードの入力が必要になります。

署名要求に自己署名して、自己署名証明書 (web-server.crt) を作成します。

openssl x509 -in web-server.csr -out web-server.crt -req -signkey web-server.key -days 365

ルート証明書のインポート

自己署名したサーバー証明書を、ルート証明書としてインポートする手順は、次の記事を参考にしてください。Mac OS, Windowsについて説明しています。

記事では、プライベート認証局の証明書をインポートしていますが、本稿で作成した自己署名証明書も同じ手順でインポートできます。記事ではroot-ca.crtとなっているところを、web-server.crtで読み替えてください。

プライベート認証局によるWebサーバーのHTTPS化

プライベート認証局を構築して、Webサーバー向けのサーバー証明書を発行する手順について紹介します。認証局の証明書をWebブラウザやOSの証明書ストアに読み込むことで、自己署名証明書を使ったサーバーに、警告なしにアクセスすることができます。

pvision.jp

2023.05.02

Webサーバーへの組み込み

Apacheに組み込んでHTTPS化した例について次の記事で紹介しています。

Apacheをプライベート認証局やオレオレ証明書でHTTPS化

Apacheで構築したWebサーバーのHTTPS化について紹介します。サーバー証明書には、プライベート認証局で署名した証明書、または自己署名した証明書を使っています。

pvision.jp

2023.05.03

変更履歴