エラーの概要ローカルの開発サイトや社内ツールをHTTPS経由で読み込もうとした際、Chromeによって接続が遮断されることがあります。ページが表示される代わりに、以下のような警告を伴う真っ白な画面が表示されます。
This site can’t provide a secure connection
ERR_SSL_KEY_USAGE_INCOMPATIBLE
このエラーは、ブラウザのアップデート直後や、新しい自己署名証明書をデプロイした際に開発者を悩ませることがよくあります。これは、証明書が主張する用途と、TLSハンドシェイク（通常はバージョン1.3）が要求する用途が一致していないことを意味します。
Chromeがブロックする理由2023年後半にリリースされたChrome 117以降、X.509証明書の検証が厳格化されました。具体的には、keyUsage拡張属性のチェックが厳密に行われるようになりました。以前のChromeでは、これらの設定が欠落していたり不適切であったりしても見逃されることがありましたが、TLS 1.3への移行に伴い状況が変わりました。
TLS 1.3は、以前のバージョンとは異なる方法でセキュリティを処理します。RSA証明書を使用する場合、プロトコルはハンドシェイク中に所有権を証明するための Digital Signature を要求するようになりました。証明書に Key Encipherment（RSAの旧標準）のみが記載されている場合や、拡張属性自体が存在しない場合、Chromeは接続を拒否します。これは、サーバーをより脆弱で古いバージョンのTLSの使用に強制する「ダウングレード攻撃」を防ぐためのセキュリティ対策です。
ステップバイステップの解決策このエラーは「詳細設定」をクリックして無視することはできません。修正するには、正しい keyUsage ビットを含むSSL証明書を再生成する必要があります。この作業にはOpenSSLを使用するのが最適です。
1. 現在の証明書を確認するまず、keyUsage フィールドが本当に原因であることを確認します。以下のコマンドを実行して、証明書ファイルの中身を確認してください。
openssl x509 -in your_certificate.crt -text -noout | grep -A 1 "Key Usage"
結果に Digital Signature が含まれていない場合、それがボトルネックです。「Key Usage」セクション自体が存在しない場合、Chromeはその証明書が古すぎてTLS 1.3では信頼できないと判断します。
2. 適切な設定ファイルを作成する汎用的なコマンドラインのデフォルト設定に頼るのではなく、openssl.cnf という専用のファイルを作成します。これにより、必要なすべての拡張属性が最初から正しく組み込まれるようになります。
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = New York
L = Brooklyn
O = TechCorp
CN = localhost
[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1
重要なポイント： digitalSignature を含める必要があります。また、ネットワーク内に残っている可能性のある古いTLS 1.2クライアントとの互換性を保つために、keyEncipherment もあわせて含めています。
3. 更新された証明書を生成する新しい設定ファイルを使用して、2048ビットのRSAキーと新しい証明書を作成します。以下のコマンドで一括実行できます。
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout server.key -out server.crt \
-config openssl.cnf -extensions v3_req
4. Webサーバーにデプロイする古いファイルを新しい server.crt と server.key に入れ替えます。Nginxを使用している場合、設定は以下のスニペットのようになります。
server {
listen 443 ssl;
server_name localhost;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
# 現代的で安全なプロトコルを強制する
ssl_protocols TLSv1.2 TLSv1.3;
}
保存後、sudo systemctl restart nginx でサービスを再起動します。変更を反映させるために、Chromeを再起動したり「HSTSキャッシュ」をクリアしたりする必要がある場合があります。
結果の確認### OpenSSLで確認する再度確認コマンドを実行し、ビットが正しく設定されているか検証します。
openssl x509 -in server.crt -text -noout | grep -A 1 "Key Usage"
以下のような成功メッセージが表示されるはずです。
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Chromeデベロッパーツールで確認する
- サイトにアクセスし、`F12` キーを押します。
- **セキュリティ**タブを開きます。
- **View Certificate** をクリックします。
- **Details** リストから **Key Usage** を探します。そこに「Digital Signature」が明記されている必要があります。
専門家のアドバイス
- **mkcertによる自動化：** 複数のローカルドメインを管理している場合、`mkcert` は非常に便利です。これらの厳格なTLS 1.3の要件をあらかじめ満たした、ローカルで信頼される証明書を自動的に作成してくれます。
- **企業のCAテンプレート：** 社内CA（Active Directory証明書サービスなど）を使用している場合、証明書テンプレートに問題がある可能性があります。「サーバー認証」テンプレートにDigital Signatureビットが含まれていることを確認してください。
- **ECDSAの利点：** RSAが一般的ですが、ECDSA証明書（P-256またはP-384曲線を使用）への切り替えも検討に値します。より高速でサイズが小さく、ハンドシェイクに本来的に `digitalSignature` を必要とします。