藤棚@あしかがフラワーパーク。こんなに美しい場所があるのですね。
以下、4K撮って出し。無編集。
機材は、Sony α6500(ILCE-6500) : SEL1018, SEL1670z, MC-11経由でEF85mm F1.8, EF70-200mm F2.8L IS II
いつも通りEXIFは残してあります。クリックすると元画像。
藤棚@あしかがフラワーパーク。こんなに美しい場所があるのですね。
以下、4K撮って出し。無編集。
機材は、Sony α6500(ILCE-6500) : SEL1018, SEL1670z, MC-11経由でEF85mm F1.8, EF70-200mm F2.8L IS II
いつも通りEXIFは残してあります。クリックすると元画像。
自己署名証明書(Self-signed certificate = いわゆるオレオレ証明書)を使ったWeb ServerにChromeの最新版(Ver 58 : 2017/04/28現在)でアクセスすると
`net::ERR_CERT_COMMON_NAME_INVALID`というエラーが出て接続ができなくなりました。その対策です。いろいろ情報は出ていますが、少数派と思われるWindows Server CAによる署名では情報が少なかったのでシェア。
時代の流れで常時TLSが一般的になりつつあり、LAN内でもWindows Server 2012 R2の証明機関(CA)機能による自己署名証明書を発行し、同じくLAN内のWeb Server (Apache2 on Linux)で利用していましたが、先週からChromeでエラーが出るようになりました。いろいろ調べてみると、最新版のChrome ver58以降から、Self-signedの証明書はエラーを出すらしく、いろいろ海外のサイト等で議論されていました。
私は、証明書(X.509v3)にマルチドメインなどに使うSAN (Subject Alternative Name) =日本語で「サブジェクト代替名」を拡張領域(フィールド)に追加し、そこにホスト名等を埋め込むことで対応することができました。この部分は、RFC2818で推奨されているようです。
<該当部分引用:from RFC2818>
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
<環境条件>
C1) LAN内オンプレのWindows Server 2012 R2にcertsrv (証明機関)および、IIS上にウェブサービスの`Microsoft Active Directory 証明書サービス`(以下Web CertSrv)が起動しているものとします。
C2) LAN内ウェブサーバーは、Apache2 (on CentOS7)とします。
C3) 証明書は、ECCなんぞハイカラなモノは避けて、RSA2048bitで保守的に。
<解説>
エラーが出る前までは、Web ServerのLinux上のOpenSSLでCSRを発行し、それをWindows ServerのWeb CertSrvで署名をして証明書をダウンロードし、Apacheのssl.confに追加していました。いろいろな海外サイトでは、Linuxサーバーの証明機関で自己署名をしているので、それでも完結(解決)できるはずですが、今回はWindows Server 2012 R2にリモートデスクトップで入り、その中にWindows版のOpenSSLを使ってCSRを作り、Web CertSrvで署名をしました。
<手順>
P1) Windows Server 2012 R2に管理者権限のあるアカウントでリモートログイン
P2) 管理者コマンドプロンプトにて、証明書へのカスタム属性対応を設定します。
c:\> certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
P3) 証明機関サービスを再起動
c:\> net stop certsvc
c:\> net start certsvc
→これで、内部CAが、SANの拡張領域に対応できます。
P4) Windows版OpenSSLのダウンロードとインストール:Shining Light Productions – Win32 OpenSSL
* 2017/04/28現在:Win32OpenSSL-1_1_0e.exe (WIN32 OpenSSL v1.1.0e)を入れました。これを書いていて気がついたのですがWin64の64bit版もあったのですね・・。Windows Server 2012 R2自体が64bit版なので、Win64を使うべきかと思います。私は気がつかずWin32版で行いました。C:\OpenSSL-Win32にインストール
P5) “C:\OpenSSL-Win32\bin\openssl.cfg”のコンフィグファイルを編集します。
[ v3_req ]という箇所を見つけて、以下の通り編集します。
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = hoge.abc.yourdomain.com
DNS.2 = hoge2.abc.yourdomain.com
DNS.3 = abc.yourdomain.com
SANに追加したいホスト名・ドメインを追加して行きます。SANはマルチドメイン用のフィールドなので何個書いてもOKだと思います。私はWebセーバーのFQDN(LAN内ローカルドメイン)も入れておきました。
P6) コマンドプロンプト(管理者)で、”C:\OpenSSL-Win32\bin”に入ります。
P7) 秘密鍵の生成(RSA2048bit) : openssl genrsa 2048 > server.key
P8) 署名リクエスト(CSR)の作成 : openssl req -new -key server.key -config openssl.cfg > server.csr
-configのスイッチで上記で編集したopenssl.cfgを読み込んでCSRを生成します。
*ここで、Common Nameは、公開するウェブサーバーのFQDNを入れておくのが無難な気がします。たぶん。
P9) Windows Server 2012 R2 CAのWeb CertSrvにアクセスしますが、いろいろな理由で付属のIE11でアクセスするのがよさそうです(Windows Server 2012 R2へリモートデスクトップで入っている状態で、その中のIE11)。LAN内の他のPCからのChromeアクセスなどでは上手くうごきませんでした。
IE11にて:https://YOUR_AD_SERVER/certsrv
*TLS(SSL)でアクセスするのでエラーが出ても続行する。TLSでアクセスしないと署名ができない。
P10) SAN属性を入力して署名をする。
*CSRのBASE64で貼り付けるのはいつも通り。
*追加属性の部分に、以下のフォーマットでSANの情報を追記する。おそらくP2), P3)の作業をしていないとこの属性を入力しても証明書にSANが追加されないと思われる。
追加属性フォーマット(SAN): san:dns=hoge.abc.yourdomain.com&dns=hoge2.abc.yourdomain.com&dns=abc.yourdomain.com
と好きなだけ追加する。
P11) 送信ボタンを押して(CAで署名)をして証明書をダウンロードし(例えばcertnew.cer)、ダブルクリックして証明書を表示する。
*赤枠にあるように「サブジェクト代替名」(=SAN)で、追加されているのが分かります。
P12) P11)の証明書(server.cer)と、P7)の秘密鍵(server.key)をLinuxサーバーにコピーし配置します。
CentOS7であれば、/etc/pki/tls/certs/以下でしょうかね。パーミッションは600。
P13) Apache2のssl.confを修正しデーモンを再起動
SSLCertificateFile /etc/pki/tls/certs/server.cer
SSLCertificateKeyFile /etc/pki/tls/certs/server.key
P14) LAN内のいろいろなホストから最新のChrome (ver58以降)でアクセス https://FQDN/
無事にエラーがなく表示できれば成功。
*Active Directoryを使っていれば当然だと思いますが、自己署名証明書をクリアするために、CAをグループポリシーで配布してある前提です。(certmgr – 信頼されたルート証明機関 > 証明書にWindows ServerのCA証明書が入っているのは前提です。
*参考:
R0) Chrome Deprecates Subject CN Matching – text/plain
R1) Configure Internal Windows CA to issue SAN certificates
R2) FAQ/subjectAltName (SAN)
R3) ssl – Generating a self-signed cert with openssl that works in Chrome 58 – Server Fault
*備忘録メモ:IISサーバー証明書インポート向け.pfx作成方法
M1) openssl pkcs12 -export -inkey server.key -in server.cer -out server.pfx
第百三回目稽古2017/4/8 | 炉・逆勝手・薄茶・濃茶