LoginSignup
5

More than 3 years have passed since last update.

chrome58で、プライベート認証局発行のサーバ証明書が無効になる場合の対処

Last updated at Posted at 2017-05-22

プライベート認証局を使って組織内だけで有効なサイトを構築しているとき、chromeブラウザが58.0以降にアップデートされると、突然、ERR_CERT_COMMON_NAME_INVALIDエラーで接続できなくなってしまう。この場合の対処法を記述する。この記事は、このサイトの要約に加筆したようなものなので、そちらのサイトも参考にしてもらいたい。

この原因は、chromeのセキュリティー基準が変わったため、当該サーバ証明書に

X509v3 Subject Alternative Name:
        DNS:example.com, DNS:*.example.com, DNS:example.jp, DNS:*.example.jp

のような、Subject Alternative Name (SAN)が必要になるためである。上記の例は、この認証局で2つのドメイン(example.comとexample.jp)に含まれるサーバを署名している場合である。当該サーバのドメイン名(証明書のCommon Name)は、XXX.example.com、あるいは、XXX.example.jpでなければならない。

設定の変更(openssl.cnf)

対処には、次の2点のみが必要である。

  1. openssl.cnfの変更
  2. 当該サーバ証明書の再署名、再インストール

なお、プライベートCA証明書を変更する必要はない。openssl.cnfは、例えばDebianの場合、/etc/ssl/openssl.cnfに存在する。変更および付加する部分を以下に示す。以下の項目(1)は因果関係のために示したもので、おそらく元から有効になっているだろう。

openssl.cnfの変更箇所
...
[ CA_default ]
...
509_extensions = usr_cert   # (1) 元々有効なので、変更の必要はない
...
[ req ]
...
req_extensions = v3_req     # (2) アンコメント(先頭の#を除去する)
...
[ usr_cert ]
...
subjectAltName = @alt_names # (3) 追加(「usr_cert」ディレクティブの最後に)
...
[ v3_req ]
...
subjectAltName = @alt_names # (4) 追加(「v3_req」ディレクティブの最後に)

# (5) 新しいディレクティブ「alt_names」と、ドメインのリストを追加
[ alt_names ]
DNS.1  = example.com
DNS.2  = *.example.com
DNS.3  = example.jp
DNS.4  = *.example.jp
...

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5