Назад | Перейти на главную страницу

Проверка подлинности Stunnel TLS с несколькими центрами доступа

Я пытаюсь защитить кластер rethinkdb за stunnel. Сервис должен поддерживать несколько центров сертификации (CA). В настоящее время я объединяю принятые центры сертификации в один файл (/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

Изменить (2): здесь я пытаюсь проверить подписанный сертификат вместо отправки корневого ЦС

$ 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:

Настроив stunnel к требовать клиентские сертификаты, используя:

verify = 2

Вы говорите stunnel отбрасывать / отказывать клиентам, не предоставившим действующий сертификат клиента. И это сообщение журнала указывает на то, что клиент не предоставил сертификат клиента и поэтому отклоняется:

SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

Мы это знаем. Теперь для Зачем Это случилось. Это сообщение на стороне клиента - наша подсказка:

[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca

Сервер TLS Запросы чтобы клиент отправил свой сертификат клиента, отправив список доверенных центров сертификации; это сертификаты CA, которые находятся в вашем /certs/ca.pem файл. Затем клиент ищет сертификат, который исходит из одного из этих центров сертификации; если у клиента вообще нет сертификата, или не имеет сертификата, полученного от одного из этих центров сертификации, то клиент вообще не предоставит сертификат.

Тот факт, что ваш клиент говорит, что он не распознает ни один из центров сертификации, отправленных сервером, означает, что ваш клиент либо а) нет клиентского сертификата, или б) его клиентский сертификат получен из центра сертификации, не входящего в /certs/ca.pem файл.

Я не уверен, какой клиент TLS вы используете, поэтому я не могу с этим помочь, но вышесказанное предполагает, что вы проверяете конфигурацию сертификата / ключа клиента для этого клиента и убедитесь, что сертификат, настроенный для использования клиентом, из один из центров сертификации в вашем /certs/ca.pem файл.

Надеюсь это поможет!