公開鍵インフラストラクチャ。 自己隔離中の証明書の発行

それはすべてどのように始まったのか

自主隔離期間の初めに、私は郵便で次のような手紙を受け取りました。

最初の反応は自然なものでした。トークンを取りに行くか、持ってくるかのどちらかですが、月曜日以来、私たちは全員家に座っていて、移動には制限があり、一体誰ですか？したがって、答えはごく自然なものでした。

そして皆さんご存知のとおり、1月11日月曜日からはかなり厳格な自主隔離期間が始まりました。また、私たち全員がリモートワークに切り替えたので、VPN も必要になりました。私たちの VPN は OpenVPN に基づいていますが、ロシアの暗号化をサポートし、PKCS#12 トークンと PKCS#XNUMX コンテナを操作できるように変更されています。当然のことながら、私たち自身も VPN 経由で作業する準備ができていないことが判明しました。多くは単に証明書を持っていなかったし、証明書の有効期限が切れていた人もいました。

プロセスはどうなりましたか?

ここでユーティリティが役に立ちます クリプトアームプkcs そしてアプリケーション CAFL63 （検証センター）。

cryptoarmpkcs ユーティリティを使用すると、自己隔離中で自宅のコンピューターにトークンを持っている従業員が証明書要求を生成できるようになりました。

従業員は保存されたリクエストを電子メールで私に送信しました。 - 個人データはどうなっているのかと尋ねる人もいるかもしれませんが、よく見ると、それはリクエストに含まれていません。そして、リクエスト自体はその署名によって保護されます。

受信すると、証明書要求は CAFL63 CA データベースにインポートされます。

その後、リクエストは拒否または承認される必要があります。リクエストを検討するには、リクエストを選択して右クリックし、ドロップダウン メニューから [決定] を選択する必要があります。

意思決定手順自体は完全に透明です。

証明書も同様に発行されますが、メニュー項目のみが「証明書の発行」と呼ばれます。

発行された証明書を表示するには、コンテキスト メニューを使用するか、対応する行をダブルクリックします。

これで、openssl (「OpenSSL テキスト」タブ) と CAFL63 アプリケーションの組み込みビューアー (「証明書テキスト」タブ) の両方を介してコンテンツを表示できるようになりました。後者の場合、コンテキスト メニューを使用して、最初にクリップボードに、次にファイルに証明書をテキスト形式でコピーできます。

ここで、最初のバージョンと比較して CAFL63 で何が変わったのかに注目してください。証明書の表示については、すでに述べました。オブジェクトのグループ (証明書、リクエスト、CRL) を選択し、それらをページング モードで表示することも可能です ([選択した項目を表示] ボタン)。

おそらく最も重要なことは、プロジェクトが無料で利用できることです。 ギタベ。 Linux 向けディストリビューションに加え、Windows および OS X 向けディストリビューションが用意されており、Android 向けディストリビューションは少し遅れてリリースされる予定です。

CAFL63 アプリケーションの以前のバージョンと比較して、インターフェイス自体が変更されただけでなく、すでに述べたように新しい機能も追加されました。たとえば、アプリケーションの説明を含むページが再設計され、ディストリビューションをダウンロードするための直接リンクが追加されました。

GOST openssl をどこで入手できるかという質問が多く寄せられ、今でも尋ねられています。伝統的に私は与えます リンク、ご提供いただきました ガレックス。このopensslの使い方が書かれています ここで.
しかし現在、配布キットにはロシアの暗号化を使用した openssl のテスト版が含まれています。

したがって、CA を設定するときに、使用する openssl として、Linux の場合は /tmp/lirssl_static を、Windows の場合は $::env(TEMP)/lirssl_static.exe を指定できます。

この場合、空の lirssl.cnf ファイルを作成し、このファイルへのパスを環境変数 LIRSSL_CONF に指定する必要があります。

証明書設定の「拡張機能」タブに「認証局情報アクセス」フィールドが追加され、CA ルート証明書と OCSP サーバーへのアクセス ポイントを設定できます。

CA が申請者から生成されたリクエスト (PKCS#10) を受け付けなかったり、さらに悪いことに、一部の CSP を通じてキャリア上でキー ペアの生成を伴うリクエストの形成を強制したりするという話をよく聞きます。また、PKCS#2.0 インターフェイス経由で (同じ RuToken EDS-11 上で) 取得不可能なキーを持つトークンに対するリクエストを生成することを拒否します。したがって、PKCS#63 トークンの暗号化メカニズムを使用して、CAFL11 アプリケーションの機能にリクエスト生成を追加することが決定されました。トークンメカニズムを有効にするために、パッケージが使用されました TclPKCS11。 CA へのリクエストを作成するとき (ページ「証明書のリクエスト」、機能「リクエスト/CSR の作成」) に、キー ペアの生成方法 (openssl またはトークンを使用) とリクエスト自体の署名方法を選択できるようになりました。

トークンを操作するために必要なライブラリは、証明書の設定で指定されます。

しかし、私たちは、自己隔離モードで企業の VPN ネットワークで働くための証明書を従業員に提供するという主要なタスクから逸脱してしまいました。一部の従業員がトークンを持っていないことが判明しました。 CAFL12 アプリケーションではこれが許可されているため、PKCS#63 で保護されたコンテナーを提供することが決定されました。まず、そのような従業員に対して、CIPF タイプ「OpenSSL」を示す PKCS#10 リクエストを作成し、証明書を発行して PKCS12 にパッケージ化します。これを行うには、「証明書」ページで目的の証明書を選択し、右クリックして「PKCS#12 にエクスポート」を選択します。

コンテナーですべてが正常に行われていることを確認するために、cryptoarmpkcs ユーティリティを使用してみましょう。

発行された証明書を従業員に送信できるようになりました。証明書付きのファイル (トークン所有者、リクエストを送信した人) または PKCS#12 コンテナが単に送信される人もいます。 XNUMX 番目のケースでは、各従業員に電話でコンテナのパスワードが与えられます。これらの従業員は、コンテナへのパスを正しく指定して VPN 構成ファイルを修正するだけで済みます。

トークン所有者に関しては、トークンの証明書をインポートする必要もありました。これを行うために、彼らは同じ cryptoarmpkcs ユーティリティを使用しました。

これで、VPN 構成に最小限の変更が加えられ (トークンの証明書ラベルが変更されている可能性があります)、それだけで、企業 VPN ネットワークは正常に動作するようになります。

ハッピーエンド

そして、なぜ人々が私のところにトークンを持ってくるのか、あるいは私が彼らのためにメッセンジャーを送る必要があるのか​​、ということに気づきました。そして、次のような内容の手紙を送ります。

答えは翌日に来ます。

すぐに cryptoarmpkcs ユーティリティにリンクを送信します。

証明書リクエストを作成する前に、トークンをクリアすることをお勧めします。

その後、PKCS#10 形式の証明書のリクエストが電子メールで送信され、証明書を発行して次の宛先に送信しました。

そして、楽しい瞬間がやって来ました。

そして、こんな手紙もありました。

そしてその後、この記事が生まれました。

Linux および MS Windows プラットフォーム用の CAFL63 アプリケーションのディストリビューションが見つかります。

ここで

• Linux32
• Linux64
• WIN32
• WIN64
• OS X

Android プラットフォームを含む cryptoarmpkcs ユーティリティのディストリビューションは次の場所にあります。

ここで

• Linux32
• Linux64
• WIN32
• WIN64
• OS X
• Android

出所： habr.com