Skip to content

MS_IISSSLSettings

Jump to bottom
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

IISのSSL設定

概要

自己署名証明書は、随分、簡単になった。

詳細

自己署名証明書

自己署名入り証明書は、

  • GUI で簡単に生成＆設定可能
    （ただし、CN が localhost か NetBIOS 名になっている）
  • OpenSSL や PowerShell などのツールを使って
    生成するケースもある。
  • 開発環境であれば、IIS Express（MS_IISExpress.md）の証明書を使用することもできる。

補足: PowerShell では 1 行で作成できる （Windows 8.1 / Server 2012 R2 以降）。

New-SelfSignedCertificate -DnsName "app.example.local", "localhost" `
  -CertStoreLocation "Cert:\LocalMachine\My"

-DnsName を複数指定すると SAN が自動的に付くため、 後述の NET::ERR_CERT_COMMON_NAME_INVALID を回避できる。

なお、この証明書をブラウザに信頼させるには 「信頼されたルート証明機関」への登録が必要で、管理特権を要する （ローカルマシンの証明書ストアの更新処理）。 開発用の手順であり、本番に持ち込まないこと。

開発用途なら、.NET SDK 同梱の dotnet dev-certs https --trust を使うほうが簡単で安全である。

証明書発行要求（CSR）の生成

  • CN に任意の FQDN 名を設定する（IP アドレスを設定することも可能）。

  • 以下のツールで発行可能

  • 証明書発行要求を生成し、公認 CA（認証局）に送信する際、
    CA の公開する手順などを参考にして、生成すると良い。

OpenSSL の例

>openssl req -out testsite.csr -key server.key -new
Country Name (2 letter code) [AU]:jp
State or Province Name (full name) [Some-State]:hoge
Locality Name (eg, city) []:hoge
Organization Name (eg, company) [Internet Widgits Pty Ltd]:open
Organizational Unit Name (eg, section) []:touryo
Common Name (e.g. server FQDN or YOUR name) []:（FQDN名）

補足（正誤・最新化）: CN（Common Name）はホスト名の識別に使われない。 RFC 2818 の時代から SAN が優先とされ、 Chrome 58 以降は CN を完全に無視する。 したがって、CSR には必ず SAN を含めること。 公認 CA も CN 単独の証明書は発行しない。

また、上記の例にある 1024 ビット RSA は現在使用できない （CA/Browser Forum の要件で 2048 ビット以上）。 -des3 による古い暗号化も避けること。

証明書発行要求に応答

Chrome で NET::ERR_CERT_COMMON_NAME_INVALID が出る場合、
SAN（Subject Alternative Name）フィールドを含める必要がある。

OpenSSL での手順

# 認証局の秘密鍵を作成
>openssl genrsa -aes256 -out server.key 2048

# 証明書発行要求に応答する（SAN を含める場合は -extfile を指定）
>openssl x509 -in testsite.csr -out testsite.crt -req -signkey server.key -days 3650 -extfile san.txt

# 応答のフォーマットを crt から PKCS#12 に変換する
>openssl pkcs12 -export -in testsite.crt -inkey server.key -out testsite.pfx

san.txt の内容

subjectAltName = DNS:（FQDN名）
  • IIS で「証明書の要求の完了」を行う。
    新しい証明書の証明書ストアは「個人」を選択する。
  • サイトに証明書をバインドして、
    「信頼されたルート証明機関」に証明書をインポートする。

移行メモ（補足）: 元ページには 「Enter Export Password:（IIS で完了するには空白に設定）」とあったが、 現在の IIS はパスワード付きの PKCS#12 も取り込める （インポート時にパスワードを入力する）。 秘密鍵を含むファイルを無パスワードで扱うのは避けること。

また、拡張子は .pkcs12 より .pfx が Windows での慣例である （証明書 を参照）。

バインドとプロトコルの設定

補足（最新化）: 証明書を用意するだけでは不十分で、 有効にするプロトコルと暗号スイートの設定が必要である。

  • SSL 2.0 / 3.0、TLS 1.0 / 1.1 は無効化する
    （PCI DSS 等でも要求される。SSL/TLS を参照）
  • IIS 自体には設定 UI が無く、 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols 配下のレジストリで制御する（要再起動）
  • 実務では IIS Crypto のようなツールで設定するのが一般的

複数サイトを 1 つの IP で HTTPS 公開するには SNI（Server Name Indication）を 使う（IIS 8 以降でバインド時に「サーバー名表示を要求する」を選択）。

証明書の有効期限切れは、IIS で最も多い障害原因の 1 つである。 Let's Encrypt（win-acme）や AD CS の自動登録で更新を自動化すること。

参考

Tags: インフラストラクチャ, Windows, IIS, 障害対応, 性能, デバッグ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally