X.509 client certificate not working through Reverse proxy

[Former Member]

Dear expert,

We are working on fiori infrastructure. Our current scope is to enable X.509 authentication for both internet and intranet. However, the intranet scenario for X.509 authentication is working fine but internet is not, we got error message of "Base64 decoding of certificate failed". For landscape, the only difference between internet and intranet is we have apache reverse proxy in DMZ. We are using gateway as fron-end server, business suite and HANA in the back-end.

As X.509 authentication works fine under intranet scenario, we assume that the configuration for X.509 for both front-end and back-end are correct. With that assumption, the issue would exist in reverse proxy. We are using apache 2.4.7 with openssl 1.0.1e, but we have upgraded the openssl to the latest version 1.0.1h for SSL certificate generation. Below are the apache configuration for X.509.

Listen 1081

<VirtualHost *:1081>

SSLEngine on

SSLCertificateFile  "D:/Apache24/conf/server.cer"

SSLCertificateKeyFile  "D:/Apache24/conf/server.key"

SSLCertificateChainFile  "D:/Apache24/conf/server-ca.cer"

SSLCACertificateFile "D:/Apache24/conf/client-ca.cer"

SSLVerifyClient optional

SSLVerifyDepth  10

SSLProxyEngine On

SSLProxyCACertificateFile "D:/Apache24/conf/internal-ca.cer"

SSLProxyMachineCertificateFile "D:/Apache24/conf/server.pem"

AllowEncodedSlashes On

ProxyPreserveHost on

RequestHeader unset Accept-Encoding

<Proxy *>

     AddDefaultCharset Off

     SSLRequireSSL

     Order deny,allow

     Allow from all

</Proxy>

RequestHeader set ClientProtocol https

RequestHeader set x-sap-webdisp-ap HTTPS=1081

RequestHeader set SSL_CLIENT_CERT  ""

RequestHeader set SSL_CLIENT_S_DN  ""

RequestHeader set SSL_CLIENT_I_DN  ""

RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"

RequestHeader set SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s"

RequestHeader set SSL_CLIENT_I_DN "%{SSL_CLIENT_I_DN}s"

ProxyPass / https://ldcinxd.wdf.sap.corp:1081/  nocanon Keepalive=on

proxyPassReverse /  https://ldcinxd.wdf.sap.corp:1081/

We are out of mind on how to resolve this issue. Please kindly help if you have any idea on it.

thanks,

Best regards,

Xian' an

[JaySchwendemann]

Hi all,

just for reference:

we had a similar problem using F5's BIG-IP Web Application Firewall as reverse proxy. We did not get this working (not sure if SAP's or F5's fault) and opted for some rather peculiar (nevertheless working) solution outlined here X.509-Based Logon to NetWeaver AS from SAP Web Dispatcher - SAP Web Dispatcher - SAP Library

Maybe this helps someone looking for a solution.

Cheers

Jens

[Former Member]

I believe the problem might be that you are using a certificate chain. Have you tried

SSLOptions              +StdEnvVars +ExportCertData

That said, SAP Web Dispatcher makes this much easier.

[Former Member]

Hi Samuli,

Really thanks for your reply.

Yes, we have tried your suggestion above in the apache configure file above, but when testing the HANA service, we got error message "Certificate could not be authenticated".

Yes, web dispatcher makes the X.509 authentication much easier as under intranet scenario, no DMZ between browser and web dispatcher. Client certificate pass through web dispatcher directly and it works perfectly this way. Not sure why it doesn' t work through apache reverse proxy.

Best regards,

Xian' an

[Former Member]

Hi Samuli,

Could you give more details on what is the impact of using a certificate chain on this issue?

thanks,

Best regards,

Xian' an

[Former Member]

Make sure you are setting the SSL options and the header variables for the request being handled by the proxy, otherwise they will only be considered for the current request. Use verbose logging in Apache (or a system after it) to make sure the header variables are correctly set in the outgoing request. The challenge with a certificate chain is that you need to forward the entire chain intact. Use Google search with "Apache Certificate Forwarding" for more information. Could you maybe use Web Dispatcher also in the DMZ? It is possible to cascade Web Dispatchers, if required.