Como garantir que o stunnel envie todos os certificados intermediários de CA?

Alguns computadores, mas não a maioria, estão rejeitando o certificado SSL do meu servidor da web. O problema parece ser que alguns computadores estão rejeitando os certificados de autoridade de certificação. O problema parece estar se manifestando no Mac OS X 10.6 quando não está totalmente atualizado.

De acordo com http://www.sslshopper.com/index.php?q=ssl-checker.html#hostname=beta.asana.com - não há problema.

De acordo com http://certlogik.com/sslchecker/ , não há documentos intermediários sendo enviados.

Meu certificado é da Starfield Technologies e estou usando sf_bundle.crtaqui: certs.godaddy.com/anonymous/repository.seam

Estou manipulando SSL no meu servidor via stunnel com o seguinte stunnel.conf:

cert = $CODEZ/admin/production/proxy/asana.pem
CAfile = $CODEZ/admin/production/proxy/sf_bundle.crt
pid =
client = no

[<forwarded port>]
accept = 443
connect = 8443

Alguma idéia do que eu poderia estar fazendo de errado?

A CAFileopção configura uma CA para usar nos certificados de autenticação do cliente; não é isso que você quer.

Em vez disso, você deseja criar o arquivo na certopção para conter toda a cadeia de certificados aplicável. Você deseja salvar uma cópia de backup desse arquivo e criar uma nova; basicamente combinando os dois arquivos, formatados assim:

-----BEGIN CERTIFICATE-----
(certificate from asana.pem file pasted here)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(intermediate certificate here; copy-paste the top chunk from the bundle)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(root certificate here; copy-paste the bottom chunk from the bundle)
-----END CERTIFICATE-----

Isso forçará o stunnel a apresentar toda a cadeia de certificados aos clientes.

Mais um boato; o openssl s_clientcomando é muito útil para testar problemas na cadeia de certificados e verificar como o serviço está apresentando seus certificados.

Edit: Ok .. a cadeia do pacote de certificados tem três níveis, mas a cadeia de confiança parece ter dois níveis. Alguma coisa não está certa.

O certificado superior ("Autoridade de certificação segura Starfield") é assinado por um emissor chamado "Autoridade de certificação Starfield classe 2" com uma impressão digital começando com ad7e1c28.. mas o segundo certificado no pacote, nomeado exatamente o mesmo que o primeiro assinante do certificado, que deve ser exatamente o mesmo certificado, tem uma impressão digital começando com 363e4734e uma data de validade 10 anos antes. Então o terceiro certificado (raiz) é o assinante do certificado intermediário incluído .. mas nenhum desses dois tem qualquer relação com o primeiro!

Se isso não fez sentido, não se preocupe. Resumo: trabalho desleixado, alguém deixou cair seriamente a bola construindo este pacote de certificados. Sua melhor aposta, então, é exportar os arquivos no formato base 64 de um navegador que valida com êxito a cadeia, colando-os no formato que listei a partir daí.

Como essa é uma bagunça confusa, sem culpa sua, adivinhei seu nome DNS e peguei o certificado, e acho que essa deve ser a cadeia completa que você precisa: http://pastebin.com/Lnr3WHc8

O Qualys SSLLabs é realmente útil para verificar sua configuração após as alterações.

https://www.ssllabs.com/ssldb/analyze.html

Verifica se você tem

• cifras fortes ativadas
• cifras fracas desativadas
• a cadeia de certificados completa e na ordem correta

Para qualquer outra pessoa que enfrenta esse problema, a postagem de Shane fez o truque, embora eu também tivesse que incluir o CAFile. Além disso, ao criar a cadeia, siga as instruções de nomeação de arquivos, conforme este artigo

Para determinar o nome do arquivo que você deve usar, você pode usar o programa c_hash que acompanha o OpenSSL (no /usr/local/ssl/miscdiretório):

c_hash some_certificate.pem
a4644b49.0 => some_certificate.pem

Portanto, no caso acima, você renomeará o arquivo para a4644b49.0.
(Observe que é um zero, não a letra 'O', após o ponto no nome do arquivo.)

Se você não possui o c_hashprograma, pode executar o comando OpenSSL apropriado para determinar o valor do hash:

openssl x509 -hash -noout -in some_certificate.pem
a4644b49

E se você está enfrentando esse problema porque está tentando usar websockets com o android cordova, adicione manualmente o wss ao seu material cordova-whitelist, pois o * inclui apenas http e https.