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>
Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
5
  • The subject line shows the correct CN. Commented Jun 11, 2013 at 15:41
  • Could you edit your message with the details of the certificate ? That might help Commented 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. Commented 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 Commented Jun 11, 2013 at 18:22
  • Note: In the apache logs, we also see "Certificate Verification: Error (20): unable to get local issuer certificate" Commented 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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.