証明書を理解

Windows VMの証明書を完全無料で自動更新する方法 この記事の内容 Windows Server（IIS）でLet’s Encryptの証明書を無料取得・自動更新する方法を解説します Certbot for WindowsはWindows版のサポートが2024年2月に終了したため、代替ツールが必要です GUIベースの「Certify Certificate Manager」とCLIベースの「win-acme」の2つのツールを実際に試します IISのバインディング設定との連携方法や、自動更新の仕組みも確認します 商用利用を検討している場合のライセンス情報についても触れます 前提環境 この記事では、以下の環境を前提として解説します。 Windows Server 2019（Azure仮想マシン） IIS（インターネットインフォメーションサービス）をWebサーバーとして使用 独自ドメインのDNSレコード設定済み（HTTP-01チャレンジに対応するため） ポート80（HTTP）および443（HTTPS）を受信許可済み Certbot for Windowsはサポート終了済み LinuxではLet’s Encryptの証明書取得に「Certbot」が広く使われています。Certbotには以前Windows版も存在していましたが、2024年2月をもってサポートが終了しています。 そのため、Certbotの公式ページでは現在Windows向けにコミュニティが管理するツールへの移行が案内されています。主な候補として紹介されているのは以下のとおりです。 Certify Certificate Manager — GUIベースのアプリケーション win-acme — CLIベースのACMEクライアント Certbot Snap（WSL2経由） 本記事では上位2つのツールをそれぞれ試した手順をご紹介します。 方法1：Certify Certificate Manager（GUIアプリ） ツールの概要 Certify Certificate ManagerはGUIで操作できるWindows向けのACMEクライアントです。Let’s Encryptを含む複数の証明書認証局に対応しており、IISとの連携が比較的簡単に行えます。 インストール 公式サイトからインストーラーをダウンロードします インストーラーを実行し、C:\Program Files 以下にインストールします インストール完了後、アプリケーションを起動します 証明書の取得手順 アプリを起動し、「New Certificate」 を選択します まず 「Register Contact」 でACMEアカウントを登録します 証明書認証局として「Let’s Encrypt」を選択 メールアドレスを入力し、利用規約に同意 「New Managed Certificate」 から証明書を作成します 表示名を設定します（例：cert-test2-dev1.example.net） ドメイン名を入力します（ワイルドカードも可） 検証方式として HTTP-01 を選択します（DNSの場合はDNS-01も選択可能） デプロイ方法として 「Auto」 を選択すると、IISへの展開まで自動で行われます 「Test」 ボタンでドメインの所有権確認をテストし、成功を確認してから 「Request Certificate」 を実行します IISバインディングの設定 証明書の取得後、IIS側でHTTPSバインディングを手動で設定する必要があります。 ...

Linux VMの証明書を完全無料で自動更新する方法 この記事の内容 Azure上にLinux VMを作成し、Apache Webサーバーを構築する手順を解説します 無料のSSL証明書発行局「Let’s Encrypt」とCertbotを使って、HTTPSを有効化します DNSレコードの設定からCertbotの実行まで、一連の流れを紹介します 証明書の自動更新の仕組みについても確認します SSHアクセスができる環境であれば、誰でも無料でHTTPS対応のWebサーバーを構築できます Azure上にLinux VMを作成する まずAzure上にLinux VMを作成します。ディストリビューションはDebian系（Ubuntu）を使用します。 VMの作成時には、公開キーを新規生成してAzureに登録します。ポートの設定では、以下の3つを開放しておきます。 SSH（22番）：接続用 HTTP（80番）：証明書発行時に必要 HTTPS（443番）：HTTPS通信用 80番ポートを開放しておく理由は、Let’s Encryptが証明書を発行する際にHTTPでドメインの所有確認を行うためです。最初の段階でポートが閉じていると、証明書の発行に失敗する可能性があります。 VMにSSH接続する VMの作成後、秘密キー（.pemファイル）をダウンロードし、ローカルのシェルからSSH接続します。 ssh -i ~/Downloads/cert-test.pem azureuser@<パブリックIP> 接続後、IPアドレスを確認しておきます。 ip a Apacheをインストールする 次に、Webサーバーとしてapache2をインストールします。 sudo apt update sudo apt install apache2 インストール後、VMのパブリックIPアドレスにブラウザでアクセスし、Apacheのデフォルトページが表示されることを確認します。 DNSレコードを設定する IPアドレスのままでは扱いにくいため、独自ドメインのDNSにAレコードを追加します。今回はAzure DNSを使用し、以下のようなホスト名を設定します。 c e r t - t e s t 1 . e x a m p l e . n e t → < V M の パ ブ リ ッ ク I P > DNSの反映後、nslookupコマンドなどで名前解決できることを確認します。 ...

この動画では、無料で本番環境にも利用できるSSL/TLS証明書をAzure VM（WindowsおよびLinux）に導入する手順について解説しています。 証明書のコストを抑えながらもセキュアな通信環境を構築したいと考えている方に最適な内容です。実際の操作画面を交えながら、証明書の取得から設定完了までの一連の流れをわかりやすく実演しています。 「無料の証明書は本番では使えないのでは？」と思っている方も、この動画を見れば考えが変わるかもしれません。Azure上でのセキュア通信設定を手を動かして学びたい方は、ぜひご覧ください。

【Active Directory証明書サービス】ERR_SSL_KEY_USAGE_INCOMPATIBLE / NET::ERR_CERT_COMMON_NAME_INVALID への対応 この記事の内容 最新のChromeやEdgeでIISの自己署名証明書が使用できなくなった問題の背景を解説します Windows Active Directory証明書サービス（AD CS）を使ったエンタープライズCAの構築手順を紹介します WebサーバーへのSSL証明書発行から、IISへのバインドまでの一連の流れを説明します CA証明書をグループポリシーで配布し、クライアントに信頼させる方法を解説します Subject Alternative Name（SAN）を含む証明書を発行するためのcertutilコマンドによる設定変更を紹介します はじめに IISの自己署名証明書を使ったHTTPS構成は、以前は「安全ではありません」という警告をスキップすれば表示できていました。しかし現在の最新版ChromeおよびEdge（Chromiumベース）では、ERR_SSL_KEY_USAGE_INCOMPATIBLEというエラーが表示され、そもそもページを表示できなくなっています。 これはブラウザ側のチェックが厳格化されたことが原因です。この記事では、正しい方法でWindows CAを立て、証明書を発行することでこの問題を解消する手順を解説します。 検証環境の構築はもちろん、企業内で証明局を立てて証明書を運用する場面にも応用できる内容です。 現象の確認 IISで自己署名証明書を作成し、WebサイトにHTTPSバインドを設定した状態でアクセスすると、以下のエラーが発生します。 E R R _ S S L _ K E Y _ U S A G E _ I N C O M P A T I B L E 「安全ではありません」の警告をスキップしようとしても、ページを表示できません。ChromeでもEdgeでも同様の挙動となります。 この問題を解消するためには、IISの簡易的な自己署名証明書の使用をやめ、Active Directory証明書サービス（AD CS） を使ってきちんとした証明書を発行する構成に切り替える必要があります。 全体の流れ 解決までの手順は大きく分けると以下の通りです。 ドメインコントローラーにAD CSをインストールしてCAを構築する CAのWebインターフェースをHTTPS化する CAでSAN（Subject Alternative Name）を有効化する WebサーバーからCSR（証明書署名要求）を作成する WebのインターフェースからSAN付きで証明書を要求・発行する 発行された証明書をIISにバインドする CA証明書をグループポリシーで配布し、クライアントに信頼させる Step 1: AD CSのインストール ドメインコントローラーに移動し、サーバーマネージャーから役割の追加を行います。 ...

【証明書基礎】WindowsのIISで自己署名証明書を作成する方法【実践編】 この記事の内容 Windows Server の IIS（Webサーバー）に自己署名証明書を作成する手順を解説します IIS マネージャーの GUI から証明書の作成・管理ができる機能を紹介します 作成した証明書を HTTPS（443番ポート）にバインドする方法を説明します 自己署名証明書が「信頼されない」理由と、その対処方法（証明書ストアへのインポート）を解説します 自己署名証明書の用途上の注意点についても触れます 前提：今回の構成 今回は Web という名前の Windows Server を用意し、そこに IIS を導入して HTTPS 構成を行います。ドメインに参加しているため、FQDN は Web.AD.local となります。 IIS（Webサーバー）の役割インストール まずはサーバーに IIS の役割をインストールします。 サーバーマネージャー を開き、「役割と機能の追加」を選択します ウィザードを進め、「Webサーバー（IIS）」にチェックを入れます 「インストール」をクリックしてインストールを完了させます インストール完了後、ブラウザで http://localhost や http://Web.AD.local にアクセスすると、IIS のデフォルトページが表示されます。 この時点では HTTPS（443番）は待ち受けていないため、https://localhost へのアクセスは接続できません。また、HTTP（80番）でのアクセスにはセキュリティ警告が表示される状態です。 IIS マネージャーで自己署名証明書を作成する IIS には、証明書の作成・管理・要求ができる機能が内蔵されています。 証明書作成の手順 IIS マネージャーを開き、左ペインでサーバー名を選択します 中央の機能一覧から 「サーバー証明書」 をダブルクリックします 右側の「操作」ペインに以下のメニューが表示されます： 証明書の要求の作成 ／ 証明書要求の完了：外部の認証局（CA）に署名を依頼するパターン ドメイン証明書の作成：Active Directory のエンタープライズ CA を利用するパターン 自己署名入り証明書の作成：今回使用するメニュー 「自己署名入り証明書の作成」をクリックします フレンドリ名（任意の識別名）を入力します 証明書ストアとして「個人」を選択します 「OK」をクリックして証明書を作成します 作成後の確認 証明書が作成されると、「サーバー証明書」の一覧に新しいエントリが追加されます。 ...

【証明書基礎】デジタル証明書についてザックリ解説【理論編】 この記事の内容 デジタル証明書は「どこかで作ってもらうもの」という誤解を解消します 公開鍵暗号の仕組み（秘密鍵・公開鍵のペア）を図解的に解説します デジタル署名によって「誰が作ったか」を検証する方法を説明します マン・イン・ザ・ミドル攻撃（中間者攻撃）の仕組みと、なぜ公開鍵暗号だけでは防げないかを解説します 認証局（CA）の役割と、証明書によって中間者攻撃を防ぐ仕組みを説明します はじめに：証明書に関するよくある誤解 デジタル証明書は、重要な技術でありながら、ちゃんと理解している方が少ない分野のひとつです。よくある誤解として、「証明書はどこかで作ってもらって、受け取るだけ」というものがあります。しかしこれは正確ではありません。この誤解を持ったままでいると、証明書の運用でつまずく原因になります。 この記事では、数学的な難しい話は省きつつ、コンセプトと大まかな動きが理解できるよう解説します。 公開鍵暗号の基礎 2つの鍵のペア 公開鍵暗号を理解するうえで最も重要な点は、秘密鍵と公開鍵は必ずセットで作成されるということです。どちらか一方だけを作ることはできません。数学的に強く関連した2つの文字列（鍵）として生成され、以下の特性を持ちます。 公開鍵で暗号化したものは、秘密鍵でのみ復号できる 秘密鍵は絶対に外に出さず、自分だけが持つ 公開鍵は世界中に公開しても問題ない 公開鍵暗号による暗号化の流れ 具体的な例で見てみましょう。AさんがBさんに秘密のメッセージを送りたい場合、次のような流れになります。 Bさんが秘密鍵と公開鍵のペアを生成する BさんがAさんに公開鍵を渡す（通信経路で見られても問題ない） AさんがメッセージをBさんの公開鍵で暗号化して送る Bさんだけが持つ秘密鍵で復号し、メッセージを読む 途中で悪意ある第三者が通信を傍受していても、公開鍵で暗号化されたメッセージは秘密鍵なしには復号できないため、内容を読まれる心配がありません。 注意点：実際の通信はハイブリッド方式 なお、実際のHTTPS通信などでは、公開鍵暗号だけですべてを処理しているわけではありません。公開鍵暗号は処理が重いため、実際にはハイブリッド暗号化方式が使われています。 共通鍵暗号：暗号化・復号に同じ鍵を使う方式で、処理が高速 公開鍵暗号で共通鍵を安全に共有し、その後は共通鍵で通信を暗号化する デジタル署名：「誰が作ったか」を証明する デジタル署名の仕組み 公開鍵暗号の応用として、デジタル署名があります。これは「このメッセージが確かに本人から来たものだ」ということを検証するための仕組みです。 署名の作成：秘密鍵を使って署名を生成する 署名の検証：公開鍵を使って署名を検証する 秘密鍵は本人しか持っていないため、秘密鍵で作られた署名は「本人にしか作れなかったもの」として機能します。 ハッシュ値を使った効率的な署名 実際の実装では、メッセージ全体に署名するのではなく、メッセージのハッシュ値に対して署名します。 ハッシュ値とは、任意のデータから一定サイズの短い文字列を生成したものです。少しでも元データが変わると、ハッシュ値は全く異なる値になります。同じデータからは必ず同じハッシュ値が得られるため、「メッセージが改ざんされていないか」の確認にも使えます。 署名と検証の流れ： 送信者がメッセージのハッシュ値を計算する そのハッシュ値に対して秘密鍵で署名を作成する メッセージと署名をセットで送信する 受信者が受け取ったメッセージのハッシュ値を計算する 受信者が署名に対して公開鍵で検証を行い、ハッシュ値を取り出す 2つのハッシュ値が一致すれば、メッセージが改ざんされておらず、正しい送信者からのものだと確認できる マン・イン・ザ・ミドル攻撃と公開鍵暗号の限界 中間者攻撃とは デジタル署名を使っても、まだ解決できていない問題があります。それが**マン・イン・ザ・ミドル攻撃（中間者攻撃）**です。 この攻撃は、通信する2者の間に攻撃者が割り込む手法です。具体的には次のように機能します。 攻撃者が偽の秘密鍵と公開鍵のペアを生成する 本来の通信相手に見せかけて、偽の公開鍵を渡す 送信者は偽の公開鍵でメッセージを暗号化して送ってしまう 攻撃者は偽の秘密鍵で復号し、内容を読む 必要であれば内容を書き換えて、本物の公開鍵で再暗号化して転送する なぜデジタル署名だけでは防げないのか デジタル署名を使っていても、最初に渡された公開鍵が偽物だった場合は意味がありません。署名の検証自体を偽の公開鍵で行うことになるため、攻撃が成立してしまいます。 問題の根本は「受け取った公開鍵が、本当に通信したい相手のものかどうかを確認できない」という点にあります。 認証局（CA）による解決 認証局とは この問題を解決するのが認証局（Certificate Authority：CA）です。認証局は、公開鍵が「確かに本人のものだ」と証明してくれる信頼できる第三者です。 証明書の発行の流れ Webサーバーなどで秘密鍵と公開鍵のペアを生成する 公開鍵を認証局に送り、本人確認を受ける 認証局が確認後、認証局の秘密鍵で署名した証明書を発行する この証明書には「この公開鍵は確かに本人のもの」という認証局のお墨付きが含まれる 証明書を使った通信の流れ サーバーが接続してきたクライアントに証明書を渡す クライアントは証明書内の認証局の署名を検証する 自分が信頼している認証局からの署名であれば、証明書を信頼する 証明書内の公開鍵を使って通信を暗号化する なぜ中間者攻撃を防げるのか 攻撃者が偽の証明書を作ろうとしても、認証局の秘密鍵を持っていないため、正しい署名を作れません。クライアントが証明書の署名を確認したとき、「信頼している認証局から発行されたものではない」と判断でき、攻撃を防げます。 ...