O proxy reverso não autenticará o SSLRequire para Salesforce.com

Question

Estou com dificuldades em tentar obter mensagens SSL por meio de um proxy reverso do Apache da salesforce.com. Estou recebendo erro 403 (proibido) quando eles tentam enviar uma mensagem para nós. Verifiquei se o proxy está funcionando solicitando o WSDL do serviço da web de back end por meio de um navegador da Web e, sem a autenticação SSL, ele funciona no IE / FireFox / etc. Se eu desligar completamente o SSLRequire, o SFDC não reportará um erro e apagará a mensagem. Infelizmente, nenhuma mensagem é enviada para o meu servidor apache. Não recebo registros, nenhuma mensagem.

Acredito que eu queira usar a diretiva SSLRequire para determinar quem é o remetente da mensagem SSL.

SSLRequire (% {SSL_CLIENT_S_DN_CN} eq "proxy.salesforce.com")

O Salesforce.com me forneceu sua chave pública, já que o CN é, de fato, proxy.salesforce.com:

Certificado:

Data:
    Version: 3 (0x2)
    Serial Number:
        0c:9e:22:84:5f:b8:55:8c:cb:c5:bf:aa:01:2a:7b:23
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 International Server CA - G3
    Validity
        Not Before: Dec  7 00:00:00 2011 GMT
        Not After : Dec  7 23:59:59 2013 GMT
    Subject: C=US, ST=California, L=San Francisco, O=Salesforce.com, Inc., OU=Application, CN=proxy.salesforce.com
    Subject Public Key Info:

Meu log de solicitações SSL mostra:

[11 / Jun / 2013: 07: 50: 28 -0400] 96.43.148.8 - TLSv1 RC4-MD5 "POST HTTP / 1.1" 416

Meu log de erros: 96.43.148.8 - - [11 / Jun / 2013: 07: 50: 28 -0400] "POST HTTP / 1.1" 403 416 "-" "Jakarta Commons-HttpClient / 3.1"

e meu log de acesso mostra:

[Tue Jun 11 07:50:28 2013] [info] Access to /opt/apache/htdocs/dev denied for 96.43.148.8 (requirement expression not fulfilled)
[Tue Jun 11 07:50:28 2013] [info] Failed expression: (%{SSL_CLIENT_S_DN_CN} eq "proxy.salesforce.com")
[Tue Jun 11 07:50:28 2013] [error] [client 96.43.148.8] access to /opt/apache/htdocs/dev failed, reason: SSL requirement expression not fulfilled (see SSL logfile for more details)

As únicas coisas que o SFDC pode me dizer neste momento, é (403) Proibido

Meus arquivos de configuração:

<VirtualHost *:8010>

# Set up logging
LogLevel info
ErrorLog veri/sfdc.error.log
Customlog veri/sfdc.log combined
CustomLog veri/ssl_request_log "%t %h %{SSL_CLIENT_S_DN_CN}c %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"


# misc directives
ServerSignature on

# Enable SSL on front end
SSLEngine On
SSLCertificateFile veri/server.crt
SSLCertificateKeyFile veri/server.key
SSLCertificateChainFile veri/intermediate.crt
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-EXP
SSLOptions -FakeBasicAuth +StdEnvVars

<location />
Order deny,allow
deny from all
allow from 96.43.148.8

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "proxy.salesforce.com")

</location>

SetEnv USING_SSL_SERVER 1
ProxyRequests off
ProxyVia On
ProxyPreserveHost On
SSLProxyEngine off


ProxyPass <SNIPPED>
ProxyPassReverse <SNIPPED>

</VirtualHost>

    

Answer 1

A autenticação SSL requer o CA Chain inteiro , incluindo a CA raiz no CAfile ou no CApath. A suposição feita por mim era que a CA raiz na loja de certificados do OpenSSL era adequada - não era.

A adição da autoridade de certificação raiz verisign permitiu que o certificado fosse verificado

<Location />
 SSLVerifyClient optional
 SSLVerifyDepth 10
 SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "<Partner CN name>")
 SSLCACertificatePath /opt/apache/veri/CA
</Location>

Não se esqueça de refazer o caminho / opt / apache / veri / CA se você estiver usando a diretiva SSLCACertificatePath.

    

Answer 2

Parece que o certificado de cliente que você recebe não tem as propriedades esperadas. Especificamente, parece que o campo de nome canônico do assunto não corresponde ao esperado "proxy.salesforce.com"

Na sua situação, eu configuraria um tcpdump na interface externa do seu proxy reverso esperando por uma conexão de 96.43.148.8. Em seguida, alimentaria o resultado desse rastreio no wireshark para que ele analisasse o handshake SSL e permitisse que você pegasse o subject.cn do certificado usado para autenticação de cliente SSL.

Isso deve lhe dar uma boa indicação do que está falhando.