Autenticação Stunnel TLS com múltiplas Autoridades

Question

Estou tentando proteger um cluster de rethinkdb por trás do stunnel. O serviço precisa suportar múltiplas Autoridades de Certificação (CA). Atualmente, concordo as CAs aceitas em um arquivo (/certs/ca.pem), mas parece que o stunnel aceitará apenas conexões que correspondam ao primeiro certificado do arquivo.

Minha configuração 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

Versão Stunnel 5.06

Log do 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

E no lado do cliente, recebo o seguinte erro:

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

Não sei por que stunnel diz que nenhum certificado retornou.

Edit: O erro está vindo do openssl. Aqui está como eu posso reproduzir:

$ 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

Editar (2): Aqui eu tento verificar um certificado assinado em vez de enviar uma CA raiz

$ 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

Legal, mas vamos mudar a ordem de 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:

    

Answer 1

Ao configurar stunnel para exigir certificados de cliente, use:

verify = 2

Você está dizendo a stunnel para eliminar / recusar qualquer cliente que não forneça um certificado de cliente válido. E essa mensagem de log indica que o cliente não forneceu um certificado de cliente e, portanto, foi rejeitado:

SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

Isso nós sabemos. Agora, por por que isso acontece. Essa mensagem do lado do cliente é nossa dica:

[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca

Um servidor TLS solicita que o cliente envie seu certificado de cliente enviando uma lista de CAs confiáveis; estes são os certificados de CA que estão no seu arquivo /certs/ca.pem . O cliente, então, procura um certificado que venha de uma dessas ACs; se o cliente não tiver um certificado, ou não tiver um certificado que venha de uma dessas CAs, o cliente não fornecerá nenhum certificado.

O fato de seu cliente dizer que ele não reconhece nenhuma das CAs enviadas pelo servidor diz que seu cliente a) não possui um certificado de cliente ou b ) seu certificado de cliente é de uma CA que não está no arquivo /certs/ca.pem .

Não tenho certeza de qual cliente TLS você está usando, portanto, não posso ajudar com isso, mas o acima sugere que você verifique a configuração do certificado / chave do cliente para esse cliente e verifique se o certificado foi configurado para uso pelo cliente TLS. cliente é de uma das CAs no seu arquivo /certs/ca.pem .

Espero que isso ajude!