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

プライベート認証局を使って組織内だけで有効なサイトを構築しているとき、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
...