web-dev-qa-db-ja.com

複数の機関によるStunnelTLS認証

Stunnelの背後にあるrethinkdbクラスターを保護しようとしています。このサービスは、複数の認証局（CA）をサポートする必要があります。現在、受け入れられたCAを1つのファイル（/certs/ca.pem）に連結していますが、stunnelはファイル内の最初の証明書に一致する接続のみを受け入れるようです。

私のstunnel構成：

foreground = yes
sslVersion = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3

[driver]
client = no
accept = 28415
connect = 127.0.0.1:28015
cert = /certs/server.pem
key = /certs/server-key.pem
CAfile = /certs/ca.pem
verify = 2

Stunnelバージョン5.06

Stunnelのログ：

2016.02.18 22:18:51 LOG5[18]: Service [driver] accepted connection from 209.136.228.130:58728
2016.02.18 22:18:51 LOG4[18]: CERT: Verification error: self signed certificate
2016.02.18 22:18:51 LOG4[18]: Rejected by CERT at depth=0: C=US, OU=Edit LLC, L=Fresno, O=Edit LLC, ST=CA, CN=jason-Lemur-Ultra
2016.02.18 22:18:51 LOG3[18]: SSL_accept: 140890B2: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
2016.02.18 22:18:51 LOG5[18]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket

そして、クライアント側では、次のエラーが発生します。

SSL handshake failed: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:590)

Stunnelが証明書が返されないと言う理由がわかりません。

編集：エラーはopensslから来ています。これが私が再現できる方法です：

$ cat ca.cert.pem incomming-ca.pem > bigca.pem
$ openssl verify -CAfile bigca.pem incomming-ca.pem 
incomming-ca.pem: C = US, OU = Edit LLC, L = Fresno, O = Edit LLC, ST = CA, CN = jason-Lemur-Ultra
error 18 at 0 depth lookup:self signed certificate
OK
$ openssl verify -CAfile bigca.pem ca.cert.pem 
ca.cert.pem: OK
$ cat incomming-ca.pem ca.cert.pem > bigca.pem
$ openssl verify -CAfile bigca.pem incomming-ca.pem 
incomming-ca.pem: OK

Edit（2）：ここでは、ルートCAを送信する代わりに、署名された証明書を検証しようとしています

$ openssl genrsa -des3 -out server.key 1024
$ openssl req -new -key server.key -out server.csr
$ openssl x509 -req -days 360 -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.crt
$ cat ca.cert.pem incomming-ca.pem > bigca.pem
$ openssl verify -CAfile bigca.pem server.crt 
server.crt: OK

かっこいいですが、bigca.pemの順序を切り替えましょう

$ cat incomming-ca.pem ca.cert.pem > bigca.pem
$ openssl verify -CAfile bigca.pem server.crt 
server.crt: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
error 7 at 0 depth lookup:certificate signature failure
140351186847392:error:0407006A:rsa  routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:
140351186847392:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:721:
140351186847392:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:233:
ssl-certificatetlsstunnel
2
zbyte

stunnelをrequireクライアント証明書に構成することにより、以下を使用します。

verify = 2

stunnelに、有効なクライアント証明書を提供しないクライアントを削除/拒否するように指示しています。そして、このログメッセージは、クライアントがクライアント証明書を提供しなかったため、拒否されたことを示しています。

SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

これは私たちが知っていることです。さて、なぜの場合、これは起こります。そのクライアント側のメッセージは私たちのヒントです：

[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca

TLSサーバーは、信頼できるCAのリストを送信することにより、クライアントがクライアント証明書を送信するように要求します。これらは、/certs/ca.pemファイルにあるCA証明書です。次に、クライアントは、これらのCAの1つからの証明書を探します。クライアントが証明書をまったく持っていない場合、またはがこれらのCAのいずれかからの証明書を持っていない場合、クライアントは証明書。

クライアントがサーバーから送信されたCAを認識しないと言っているという事実は、クライアントにもa）がないことを示しています。クライアント証明書、またはb）そのクライアント証明書は、/certs/ca.pemファイルにないCAからのものです。

使用しているTLSクライアントがわからないため、サポートできませんが、上記では、そのクライアントのクライアント証明書/キーの構成を確認し、クライアントが使用するように構成された証明書が/certs/ca.pemファイル内のCAの1つ。

お役に立てれば！

2
Castaglia