私は現在socatを使っておもちゃhttpsサーバーを設定しようとしていますが、次のことを行っています。
ここで説明されているように:SOCATを使用したOPENSSL接続の例
cert() {
openssl genrsa -out $1.key 2048
openssl req -new -key $1.key -x509 -days 3653 -out $1.crt
cat $1.key $1.crt > $1.pem
}
$ cert server && cert client
$ openssl dhparam -out dhparams.pem 2048 # see [1]
$ cat dhparams.pem >> server.pem
Socat SSL - SSLルーチン:SSL3_CHECK_CERT_AND_ALGORITHM:dhキーが小さすぎます。
その後、ターミナル1で実行します。
$ socat ssl-l:1443,reuseaddr,fork,cert=server.pem,cafile=client.crt,verify=1 exec:'uptime'
ターミナル#2で次を実行します。
$ socat - ssl:localhost:1443,cert=client.pem,cafile=server.crt
すべてが期待どおりに動作し、稼働時間が確保されますが、そうなると
$ curl --cert client.pem --cacert server.crt https://localhost:1443
curl: (51) SSL: unable to obtain common name from peer certificate
失敗します。
HTTPSの理解が少し不安定であることを認めているので、いくつかの質問があります。
- なぜ失敗したのですか?
- クライアント証明書をサーバーに送信するのはなぜですか?ウェブサーフィン中にはこのようなことは起こりませんか?
ベストアンサー1
なぜ失敗したのですか?
あなたの指示が部分的に正しくないようです。
$ openssl req -new -key server.key -x509 -days 3653 -out server.crt
// enter fields... (may all be empty when cert is only used privately)
プロンプトされたフィールド(少なくとも「標準」アップストリームプロファイルの場合)req -new -x509
は、生成された証明書(または証明書のないCSR)-x509
のサブジェクト名として使用されます。 (自己署名証明書の場合、発行者名はサブジェクト名と同じであるため、同じデータが表示されます。)
HTTPS サーバーの場合、接続が詐欺師ではなく有効なサーバーに接続されていることを確認するには、サーバーの証明書がrfc5280(信頼できるCAなどの署名)に従って有効であり、証明書はURLで指定されたサーバーに発行する必要があります。証明書プリンシパル名の「一般名」フィールドは、必要なサーバーまたはプリンシパル代替名拡張子と一致する必要があります。(しばしば略語として、SAN(MicrosoftではUCCとも呼ばれる)またはMicrosoftの影響を受けた製品)が存在し、そのための項目を含める必要があります。バラよりRFC2818。 OpenSSLがこのフィールドを要求する理由は次のとおりです。
Common Name (e.g. server FQDN or YOUR name) []:
ほとんどの人はFQDNを介してサーバーを識別するURLを使用するため、例外があります。したがって、このプロンプトに応答する必要がありますlocalhost
。 SANは公式に好まれた選択肢と見なされ、すべての「実際の」CA(Verisign Symantec Digicert、GoDaddyなど)は2000年頃からSANを実装しましたが、OpenSSLを使用してSANを実装するにははるかに多くの作業が必要です。 OpenSSLのSANについて Stackにはすでに多くの質問があります。必要なものが見つからない場合は、私のノートでいくつか探してみましょう。 1つの例外は、Chrome / chromiumを使用したい場合です。数ヶ月前から必要証明書にSAN(正しいサーバー名を含む)があり、subject.CNは許可されなくなりました。これについても疑問があります。
HTTPS以外のSSL / TLSベースのプロトコルは異なる場合があり、FTPS SNMPS LDAPSなどの空のトピック名は実際には問題ありません。
クライアント証明書をサーバーに送信するのはなぜですか?ウェブサーフィン中にはこのようなことは起こりませんか?
それは本当にウェブを意味しますか、それともワールドワイドウェブを意味しますか? SSL / TLSプロトコルはクライアント証明書によるクライアント認証をサポートしますが、ネットワークのセキュリティ(HTTPS)部分にあるWebサーバーのうち、この機能を使用するWebサーバーはほとんどありません。クライアントを認証する必要があるほとんどのWebサーバーはHTTPレベルの方法を使用します。Stackが提供するオプション。これにより、UIを制御し、すべてのブラウザで一貫して作成し、それに応じてガイダンス、ヘルプ、およびサポートを提供できますが、クライアント証明書のUIはブラウザまたはプラットフォームによって異なる方法で実装され、しばしば少しの技術的能力または少なくともインテリジェンスと忍耐力が必要ですします。ほとんどのサイトでは、ほとんどのユーザーがこれを実行できないか、少なくとも実行しないと想定しています。
クライアント証明書を使用する少数のWebサーバーには、一般的にパブリックCAおよび/または信頼できる第三者(政府または銀行など)によって発行された証明書が必要です。証明書が必要な場合もあります。 。使用自己署名クライアント証明書には、次のものが必要です。ユーザーは事前に証明書を提供します。偽造された証明書を一度受け入れることができる人は誰でも長年にわたって詐欺的に接続できるため、このプロビジョニングプロセスは非常に安全でなければなりません。
OTOH、両端を「所有」すると、サーバー管理者はクライアント管理者を簡単に識別して信頼でき、その逆も同様です。 AIUI OpenVPNキー交換はそれを使用します(自己署名または一時的なCA証明書を持つSSL / TLS)。
追加の回答:上記の変更により、接続のTLS層は正常に機能するはずですが、出力がuptime
有効なHTTP応答ではないため、設定はまだHTTPSサーバーとして機能しません。 HTTPヘッダを生成するために必要なものそしてCGI "ページ"が実際のWebサーバー(HTTPまたはHTTPSの場合)で動作するのとほぼ同じ方法でコンテンツ。