OpenVPNのubuntu docs の説明にこの部分があります。
次のファイルをクライアントにコピーします。
- /etc/openvpn/ca.crt
- /etc/openvpn/easy-rsa/keys/hostname.crt
- /etc/openvpn/easy-rsa/keys/hostname.key
- /etc/openvpn/ta.key
最初に機密証明書の共有を要求する代わりに、vpnスキームがクライアントにアクセスを許可するために管理者にクライアントの公開鍵のインストールのみを要求することは可能ではないでしょうか?これを行う他のVPNはありますか?
すべてのファイルの内訳を見てみましょう。それらが機密であるかどうか、そしてそれらがどこから来たのかを見てみましょう。
公に使い捨て可能な、これはVPNの認証局の証明書です。誰とでも共有でき、クライアントがVPNサーバーを確認できるようにします。
これはクライアントを識別する証明書です。これはクライアントの秘密鍵によって署名され、それからCAの鍵によって署名されました。
これはクライアントの秘密鍵です。あなたが見ているドキュメントでは、クライアント証明書がそこのキーによって署名され、次にCAキーによって署名されるように、便宜上サーバー上で生成されました。秘密鍵を生成し、サーバーがそれを見ることなくクライアント上に保持することもできますが、その場合、プロセスがはるかに複雑になります。興味がある場合は、グーグル検索を行うか、別の質問を開いてプライベートCAを作成してください。これは、まったく別の部門です。
これは少し特殊なので、 http://openvpn.net/index.php/open-source/documentation/howto.html で見つけた関連を貼り付けます。
tls-auth
Tls-authディレクティブは、整合性検証のためにすべてのSSL/TLSハンドシェイクパケットに追加のHMAC署名を追加します。正しいHMAC署名が付いていないUDPパケットは、それ以上処理せずにドロップできます。 tls-auth HMACシグネチャは、SSL/TLSによって提供されるセキュリティに加えて、さらに高いセキュリティレベルを提供します。それはから保護することができます:
- OpenVPN UDPポートでのDoS攻撃またはポートフラッディング。
- どのサーバーのUDPポートがリッスン状態にあるかを判別するためのポートスキャン。
- SSL/TLS実装におけるバッファオーバーフローの脆弱性。
- 無許可のマシンからのSSL/TLSハンドシェイクの開始(このようなハンドシェイクは最終的に認証に失敗しますが、tls-authははるかに早い時点でそれらを遮断できます)。
Tls-authを使用するには、標準のRSA証明書/キーに加えて使用される共有秘密キーを生成する必要があります。
openvpn --genkey --secret ta.key
はい、クライアントのキーをローカルで生成し、正しいキーを使用したことを確認する適切な方法があれば、ta.keyを除いて、必要なすべてをクリアテキストで共有できます。システムはta.keyがなくても安全です。これは部外者を制限するための単なる追加手段です。そうは言っても、それは本当に良い尺度です。
簡単に言えば、公開鍵(hostname.crt
)は、数学的には秘密鍵から派生であり、クライアントが実際に正しい秘密鍵を提起していることを確認するために使用されます(保護されている場合はそれを復号化できます)。
そのため、クライアントに秘密鍵を安全な方法で確実に取得する必要があります。これがないと、サーバーの公開鍵は無意味になります。
他のものについては:ca.crt
は、クライアントが実際に正しいサーバー(MITMではなく)に接続していることを確認するために使用され、ta.key
は共有クライアントとサーバーの両方のシークレットです(基本的には、「あなたが持っているもの」)。
これは、証明書を使用するすべてのVPNソリューションに共通の問題です。共有シークレット(PPTPを使用する場合のユーザー名とパスワードなど)のみを使用できますが、これは1)パスワードがあまり長くないため通常は安全性が低く、2)MITM攻撃から保護されません。
はい、OpenVPNを構成することは可能です。そのため、クライアントの公開鍵とクライアントの証明書をサーバーにインストールするだけでよく、サーバーの公開鍵とサーバーの証明書をクライアントにインストールするだけで済みます。
公開鍵と証明書は機密ではありません。これらは機密情報ではありません。何らかの理由で必要な場合は、安全に世界中と共有できます。秘密鍵は公開されません。