OpenSSLベースの証明機関

私がシステム管理者として働いていたとき、私はモスクワの数十の支店、イントラネット、およびメールにVPNを実装する必要がありました。 同時に、システム全体を考え出し、その展開を1人で整理する必要がありました。 予算は1万5千ドルで、4年前でした。しばらくの間、私は正直に手頃な価格のソフトウェアを見つけようとしましたが、急流で何かを見つけようとしました-それは空です。 結果はOpenSSLとOpenVPNです。 この入門テキストでは、OpenSSLについてお話したいと思います。



最終的に展開されました：

• 証明書発行センター（CA-認証局、別名CA-認証局、ロシア語では証明書の発行を許可された組織）、
• クライアント証明書によるアクセス許可があるイントラネットサイト、
• サーバー、クライアント、および動的ルーティングの相互認証を備えたVPN
• 同じ証明書を使用した企業IMサーバー上のクライアントの承認。

どうやら、システムは今までに死にました...解雇後、ルート証明書の有効期限（つまり、発売日から2年）までの期間はわかりません。



以下は、一般ユーザーよりも企業の技術者にとって興味深いものです。 条件：組織は国営ではなく、お金を節約するという目標があります。研究開発で6つのゼロと金額を交換せずに「モノ」を試してみたいという要望があります。



読者は、VPN（この場合は仮想プライベートネットワーク）とSSL（Secure Sockets Layer）の概念と、 x.509形式の電子証明書であるという事実に精通していることを前提としています。

CA

結果のシステムでは、証明書を更新、失効、認証、コード、ファイル、メールの暗号化に使用し、侵害された場合は、CA全体を殺すことなくブランチを失効させることができます。 これを行うには、OpenSSL構成ファイルを慎重に検討し、証明書失効リスト（CRL）とCAの正しい階層を生成する手順を作成する必要がありました。 その場合にのみ、選択した実装で証明書の使用が許可されました。 そして、「 はい、私はまだこの証明書を信頼していますが、期限切れで誤って発行されており、これをまったく意図していません 」というボタンをクリックする自動プロセスではありません 。



電子デジタル署名証明書の問題と使用は、技術的なだけでなく組織的なプロセスでもあることを覚えておくことが重要です。これがないと、この種の保護を使用するメリットはなくなります。 たとえば、すべての証明書のリリース後、CAを備えたディスクは、 USBである場合は取り外しまたは切断し、安全な場所に置くことをお勧めします。 そして雑誌を始めてください。

サイト

イントラネットサイト（ 最初の階層-Apache、その背後にあるもの-重要ではありません ）では、多要素認証が実装されました。 通常、認証における最初の唯一の要素は、ユーザー名とパスワード、またはユーザー名とPINコードの知識です。 クライアントのみがサーバーに表示され、サーバーはそれが彼であることを証明する必要はありません。したがって、ログイン/パスワードの盗用および/またはサーバーの置換の可能性があります。 私の場合、これは受け入れられなかったため、証明書を持つ必要性がログイン/パスワードの知識に追加されました。 CAからの証明書は、パスワード付きのPKCS12（PFX）形式でアップロードされました。



次のようなものがサーバー構成に追加されました：



<Location /location1>

SSLOptions +FakeBasicAuth +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 2

SSLRequire %{SSL_CLIENT_I_DN_CN} in {"My LTD OpenSSL CA"}







つまり My LTD OpenSSL CAによって証明書が発行されたすべての人を許可します（ 実際には、もちろん名前は異なります ）



名前でアクセスを制限することもできます。



<Location /location2>

SSLOptions +FakeBasicAuth +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 2

SSLRequire %{SSL_CLIENT_S_DN_CN} in {"Ivan A Ivanov", \

"Petr B Petrov"}







次の構成を使用して、サーバーログに書き込まれます。



CustomLog ../logs/ssl/ssl_request.log \

"\"%t\",\"%h\",\"%{SSL_CLIENT_S_DN_CN}x\",\"%r\",\"%s\"" env=!dontlogit

証明書の配布

キーとともに受信した証明書は、非常に一般的なケースであるユーザーのコンピューターにインストールされました（ レジストリにあり、PINコードで暗号化されています ）が、このコンピューターでのみ証明書を使用でき、オペレーティングシステムを再インストールする場合は、もちろん、証明書を再度受信する必要があります秘密鍵はコンピューター上で生成され、CAを訪れたときにディスケットで渡されることはありません。これは実際には秘密鍵の所有者になるためです（ 単純な可能性があるため） CAにも「電子署名」を提供します。また、特定のレベルのスロベネスで-CA内のすべての管理者が互いに置き換えます。 ただし、CAには、証明書の「復元」のためのサービスを提供する機会があります。



なぜなら 私自身はCAでしたが、技術専門家による「メモリ」のための証明書のコピーやそのような「サービス」から免れました（そうではありませんでした）。



証明書は、ハードウェアストレージデバイス（Aladdin USBキー）で現場の従業員に発行されました。 この目的のために提供された（および提供している）銀行およびCAは、フロッピーディスクまたは最新のオプションであるフラッシュドライブを使用します。 これはより便利ですが、別の危険につながります-複製を作成する機能です。 理想的なケースでは、キーと証明書はスマートカードに保存する必要があります。スマートカードは、ピンコードでさらに保護され、独自の暗号プロセッサを搭載しています。乱数発生器は、キーを取得する場合、潜在的なクラッカーの可能性を大幅に減らすと考えられています。 さらに、スマートカードは実質的にコピーできません。

Aladdin eToken USBキーは、そのようなカードであり、USBスティックの形式にすぎません。

認証の場合、手順に必要な少量のデータのみが暗号化されますが、必要に応じて、クライアントとサーバー間のすべてのトラフィックも暗号化できます。 多数のクライアントを備えたサーバーで暗号化に証明書を使用する必要がある場合、サーバーにもっと深刻なもの、たとえば暗号カード、無料のIBM HTTP Server（ 実際には同じApache ）、それらの一部を置く必要がありますサポートします。

もちろん、普通のプラスチックカードのように見えるスマートカードの使用を気にする人はいませんが、そのようなカードを使用する必要があるすべての職場には、カードリーダーが必要です。



CAから証明書を受け取り、「トークン」に配置し、PINコードでトークンを閉じた後、2要素の双方向認証を実行する機会が得られます。 最初の要素-トークンがあり、2番目の要素-それからPINコードを知っています。 証明書を取得すると、サーバーが実際に本人であることを確認できます。この場合、bobik.ruとbobik.ruを混同することはできません。2番目のバージョンのロシア語「o」は名前の不一致（ -異なる文字 ）。

証明書失効リスト

取り消された証明書（CRL）のリストがサーバーの設定に登録（および定期的に更新）されたという事実により、次のようなユーザーのサイトへのアクセスをすぐに一時停止できました。 USBキーを紛失した（または紛失した疑いがある）場合、または従業員を解雇した場合。



多くの国内CAはCRLの場所を示しますが、リスト自体をアップロードまたは更新することを「忘れ」ます。たとえば、同じOutlookが失効したリストに対して証明書を検証できず、警告を発行した場合、電話コンサルタントはこの警告を無視するよう提案する場合があります。 クライアントが別のサーバーである場合、証明書を検証できない場合は、単に切断されます。



必要に応じて、同じ秘密キーで証明書が再発行されたため、以前に暗号化されたデータにアクセスできなくなりました。

OpenSSLのデバッグ

一般的に、誰もが証明書は良いことだと理解しており、証明書を正しく発行する必要があります。 かなり長い間侵入し、数百ページの「ドキュメント」を調べた後（ 実際、IntuitのPKIと暗号化に関するチュートリアルでした ）、当時のインターネットで利用可能なopenSSL構成の例は、「 遊び回る 」目的にのみ適していました。しばらくの間、私が発行した証明書がOutlook、Thunderbird、Firefoxで機能しないという事実に直面していました。 IEは最も雑食性であることが判明しました。



物事をもう少し真剣にするには、少しまっすぐにする必要があります。

• ルートCA証明書を発行する前にシステムを1年以上使用したい場合は、日数を3650に増やしてから返してください。ユーザー証明書の場合は、1年または6か月残すことをお勧めします
• [CA_default]セクション
  
  unique_subjectパラメーターを「yes」に設定します-これにより、2つの同一の証明書を発行できなくなります
• [user_cert]セクション
  
  加える
  
  ExtendedKeyUsage = clientAuth
  
  
  
  
• サーバーセクションは次のようになります
  
  [ server_cert ]

basicConstraints = CA:FALSE

nsCertType = server

keyUsage = digitalSignature, keyEncipherment

extendedKeyUsage = nsSGC, serverAuth
  
  
  
  
• セクション[v3_ca]
  
  変わる
  
  basicConstraints = CA:TRUE, pathlen:5
  
  
  
  
• nsCertTypeとkeyUsageのコメントを外します
• 加える
  
  extendedKeyUsage = serverAuth, clientAuth
  
  
  
  

いつものように- 準備ができた設定 。

証明書発行の自動化

自動化の次のステップは、証明書のリストを表示するインターフェースを作成することです。 リストには明確な形式のindex.txtという名前があり、HTAでインターフェイスを作成しました。 デバッグを簡素化するために、HTAは個々のプロシージャのバッチファイルを呼び出しました。 必要なセットは次のとおりです。

1. 環境変数を設定するための別のファイル
2. 任意の証明書の発行-最小限の設定、一連の質問、質問、たとえばパートナー向けの証明書の発行、CAへのサインイン
3. CAルート証明書の発行-ハンドルを使用してツリーが構築される場合、1回または数回呼び出されます
4. サーバー証明書の発行は理解でき、opensslは-extensions server_certパラメーターで呼び出され、[server_cert]セクションの設定には必要なパラメーターが含まれている必要があります。別の違いは、PFXにパッケージ化されず、キーのアンパックバージョンが作成されることです。
5. ユーザー証明書の問題
6. 証明書の失効は興味深いプロセスです。発行された証明書のアーカイブ（自分で行う必要があります）から、必要な証明書を（名前で、シリアル番号で）抽出し、それからすでに失効しています
7. ユーザー証明書の更新-最初に、古い証明書が取り消され（バッチファイルNo. 6）、次に古いキーの新しい証明書が作成されます（バッチファイルNo. 5）
8. 失効した証明書のリストを更新するのは簡単なコマンドですが、私の場合はPerlでスクリプトを実行し、リストを作成してLotus Dominoディレクトリ（ アドレス帳と呼ばれることもある ）に配置しました。 CRLを配布するほぼ標準的な方法です）

おそらくすべてのツールです。 いい紹介があります。