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

Обратный прокси-сервер не аутентифицирует SSLRequire для Salesforce.com

Я изо всех сил пытаюсь получить сообщения SSL через обратный прокси-сервер Apache от salesforce.com. Я получаю ошибку 403 (запрещено), когда они пытаются отправить нам сообщение. Я подтвердил, что прокси-сервер работает, запрашивая WSDL из серверной веб-службы через веб-браузер, и без проверки подлинности SSL он работает из IE / FireFox и т. Д. Если я полностью отключу SSLRequire, SFDC не сообщит об ошибке и удалит сообщение. К сожалению, на мой сервер Apache сообщения не отправляются. Я не получаю ни логов, ни сообщений.

Я считаю, что хочу использовать директиву SSLRequire для определения отправителя сообщения SSL.

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

Salesforce.com предоставил мне свой открытый ключ, поскольку CN на самом деле является proxy.salesforce.com:

Сертификат:

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:

Мой журнал запросов SSL показывает:

[11 / июн / 2013: 07: 50: 28 -0400] 96.43.148.8 - TLSv1 RC4-MD5 «POST HTTP / 1.1» 416

Мой журнал ошибок: 96.43.148.8 - - [11 / июн / 2013: 07: 50: 28 -0400] "POST HTTP / 1.1" 403 416 "-" "Jakarta Commons-HttpClient / 3.1"

и мой журнал доступа показывает:

[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)

Единственное, что SFDC может сказать мне на данный момент, это (403) Forbidden

Мои файлы конфигурации:

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

Для аутентификации SSL требуется весь Цепочка ЦС, включая корневой ЦС, который должен находиться в CAfile или CApath. Мною было сделано предположение, что корневой ЦС в хранилище сертификатов OpenSSL был адекватным - это не так.

Добавление используемого корневого ЦС Verisign позволило проверить сертификат

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

Не забудьте перефразировать путь / opt / apache / veri / CA, если вы используете директиву SSLCACertificatePath.

Похоже, что полученный вами сертификат клиента не обладает ожидаемыми свойствами. В частности, похоже, что поле канонического имени субъекта не соответствует ожидаемому "proxy.salesforce.com"

В вашей ситуации я бы установил tcpdump на внешнем интерфейсе вашего обратного прокси-сервера, ожидая подключения от 96.43.148.8. Затем я передал бы результат этой трассировки в wirehark, чтобы он проанализировал рукопожатие SSL и позволил вам получить subject.cn сертификата, используемого для аутентификации клиента SSL.

Это должно дать вам хорошее представление о том, что именно не получается.