以前の記事ではNTLM認証だったので、今回はドメイン認証で構築します。
NTLM認証はエンタープライズ環境を前提としておらず、なかばお遊びで作った環境のため証明書は自己証明書でした。
今回はドメイン認証を行うエンタープライズ環境を前提にSMB over QUICを構築しようと思い、正規の証明書を利用して環境を構築します。
しかしながら完全自前(つまり支払いも全部自腹)で環境を準備しているため、正規の証明書は無料のLet’s Encrypt証明書を利用します。
今まで何気に正規の証明書を作成して検証することが少なかったので、今更ながらLet’s Encryptで証明書を作成する方法をまとめました。
今更わざわざLet's Encryptを使って証明書を発行する記事を書くのはなんでなの？
Windowsで任意のFQDNをDNS-01と言われるDNSチャレンジ(ドメインのテキストレコードに任意の文字列を入力し、証明書登録者がドメインの正規の保持者であることを認証する方法)が検索しても出てこなかった(私が見つけられなかっただけかもしれませんが・・・)ので手法をまとめてみます。
Let's Encryptで証明書を発行するツールがWebサイトも含めると複数あり、Linuxを使うとデフォルトでインストールされていたり、WindowsでもIIS環境でそのまま利用できるように自身のFQDNを登録してhttp-01(httpチャレンジ)のディレクトリに自動配置したり、様々な機能を使ったサイトはなんぼでも見つかるのですが、今回はSMB over QUIC環境を構築するため、インターネットに公開されているWebサイトでの証明書利用ではないのでIISは動いていませんし、http-01での認証を前提とした自動配置の機能も不要です
SMB over QUICを構築する際に利用する証明書を考えた場合、DNS-01で最低限ドメインの保持者が証明書の発行者であることが証明されれば十分です。
ドメイン保持者の証明のためにインターネット公開されているWebサーバを準備することは管理上無駄であるため不採用としました。
他にもDockerを使ったりWSL使ったりという手法は出てきたのですが、素のWindowsでやってる方法がなかなか見つかりませんでした。
私はDockerに関してはお恥ずかしながら使ったことがなく、WSLは業務で使っていましたが自前のPCでは使っていませんでしたので、一般的なWindows PCを持っていればDockerやWSL、インターネットに公開されているWebサーバなどの事前準備が不要という意味で一番簡単と思われる素のWindows Client OS、今回はWindows 10 Proでやってみました。
また前置きが長くなっちゃいましたね。
証明書作成の事前準備
事前準備不要で一番簡単と言いましたが、Let's Encryptで証明書を発行する専用のツール、certbot.exeをインストールする必要があります。
ではさっそく実施してきましょう。
まずはコマンドプロンプトを管理者権限で開き、winget install certbotというコマンドを実行します。
一応コピー用に
winget install certbot
この形式で記載しておきます。
これでLet's Encryptの証明書を作成する専用ツール、certbot.exeとその関連ファイルがインストールされます。
証明書発行
certbot.exeをインストールすると、デフォルトでC:\Program Files\Certbot\binにcertbot.exeが配置されます。
パスを通すことも考えたのですが、ごちゃごたしたくなかったのでパスを通さずこのまま使います。
今後も使うのであればこのディレクトリ構造を忘れてしまうと面倒なのでパスを通しておきましょう。
実際にLet's Encryptでエンタープライズユーザーの利用に耐えられる環境を構築するかわかりませんが、仮に構築するのであれば証明書の更新作業が発生しますので、パスを通しておいた方が良いと思います。
cd C:\Program Files\Certbot\bin
certbot.exe certonly -d [FQDN] --manual --preferred-challenges dns
[FQDN]の部分は皆さまの環境に合わせて変更してください。
私が利用するSMB over QUICのファイルサーバのFQDNがwin2k25-03.sh-style.infoなので、実際に実行するコマンドは
cd C:\Program Files\Certbot\bin
certbot.exe certonly -d win2k25-03.sh-style.info --manual --preferred-challenges dns
となります。
簡単にオプションの説明
certonlyが証明書発行のみというオプションになります。
-dは発行する証明書のFQDNの指定です。
--manualはドメインの保持者の認証を手動で行う、というオプションになり、次のオプションとセットで利用します。
--preferred-challenges dnsは先のオプション、--manual と合わせて使うことでDNS-01認証を行う、ということになります。
最終的にはこのオプションが知りたかっただけなんですよね。
発行された証明書を取り出す
C:\Certbot\archive\[FQDN]というフォルダが自動生成され、ここにcert1.pem、chain1.pem、fullchain1.pem、privkey1.pemという4つのファイルが生成されます。
これら4つのファイルを今度はSMB over QUICが動作するWindows Server 2025にインストールできる形式、pfx形式に変換します。
pfxに変換する
私が調べた限り、Windowsのネイティブの機能では実施できなさそうでした。
certutilがあるのでこれで変換可能かな？軽く考えていたのですが、certutilを使ってpfxからpemへの変換はできても、逆のpemからPFXへの変換はできないようです。
なのでopensslでやります。
opensslのインストールはWindowsにやっても良いんですが、手元にUbuntuサーバがあるのでこれて変換しちゃいます。
Let's Encryptだとこういう手間が発生しますが、エンタープライズ環境だと有料の証明書発行サービスを使うでしょうから、こういう手間は発生しないと思います。(お客様にも依るかもしれませんが・・・)
はい。
またしても前置きが長くなっちゃったのでさっさとコマンド紹介ます。
先のpemファイルのうち、fullchain1.pem、privkey1.pemの2つのファイルをUnbutuの任意のディレクトリに配置し、以下のコマンドを実行します。
openssl pkcs12 -export -in fullchain1.pem -inkey privkey1.pem -out [pfxのファイル名]
[pfxのファイル名]は各自の環境に合わせてください。
私は「名は体を表す」のが好き(単に命名を考えるのが面倒)なので、以下のようにしました。
openssl pkcs12 -export -in fullchain1.pem -inkey privkey1.pem -out win2k25-03.sh-style.info.pfx
はい。
わかりやすいですね。
これでpfxファイルに変換できたので事前準備は終わりです。
本日はここまで。