1

I am struggling trying to get a SSL messages via an Apache reverse proxy from salesforce.com. I am getting 403 (forbidden) error when they attempt to send a message to us. I have verified the proxy is working by requesting the WSDL from the back end web service via a web browser and without the SSL authentication, it works from IE/FireFox/etc. If I turn off the SSLRequire completely, SFDC does not report an error, and deletes the message. Unfortunately, no messages are sent to my apache server. I get no logs, no message.

I believe that I want to use the directive SSLRequire to determine who the sender of the SSL message is.

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

Salesforce.com provided me with their public key, as the CN is in fact proxy.salesforce.com:

Certificate:

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:

My SSL Request log shows:

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

My errorlog: 96.43.148.8 - - [11/Jun/2013:07:50:28 -0400] "POST HTTP/1.1" 403 416 "-" "Jakarta Commons-HttpClient/3.1"

and my access log shows:

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

The only things SFDC can tell me at this point, is (403)Forbidden

My config files:

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

2 Answers 2

0

It looks like the client certificate you receive does not have the expected properties. Specifically, it looks like it's subject canonical name field isn't matching the expected "proxy.salesforce.com"

In your situation, I would setup a tcpdump on the external interface of your reverse proxy waiting for a connection from 96.43.148.8. I'd then feed the result of that trace into wireshark so that it would parse the SSL handshake and allow you to grab the subject.cn of the certificate used for SSL client authentication.

That should give you a good indication of what is failing.

5
  • The subject line shows the correct CN.
    – user176514
    Jun 11, 2013 at 15:41
  • Could you edit your message with the details of the certificate ? That might help
    – Stephane
    Jun 11, 2013 at 15:56
  • I'm not sure what I can share, the certificate in the Client Key Exchange packet of the network trace is for Common Name (CN) proxy.salesforc.com, signed by Verisign -- this is the key SFDC provided. It is the text in teh very top of the initial message.
    – user176514
    Jun 11, 2013 at 17:59
  • Additional note: The fault packet that follows claims "Unknown CA" -- I have downloaded and installed (in /var/ssl/certs - yes, I did the rehash) with the latest PEM certificates from Verisign, who signed the CA from Salesforce.com
    – user176514
    Jun 11, 2013 at 18:22
  • Note: In the apache logs, we also see "Certificate Verification: Error (20): unable to get local issuer certificate"
    – user176514
    Jun 11, 2013 at 18:50
0

The SSL autentication requires the entire CA Chain, including the root CA to be in the CAfile or CApath. The assumption made by me was that the Root CA in the OpenSSL certs store was adequate - it wasn't.

Adding the verisign Root CA used allowed the certificate to be verified

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

Don't forget to rehash the /opt/apache/veri/CA path if you are using the SSLCACertificatePath directive.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .