SSL Sticky feature...

We were trying SSL Sticky feature with two real http servers and it
does not seem to work..
When i configure ssl sticky for the https VIP, it apparently, sticks
the connection to the first leg i.e, the SSL Termination. However, the
second leg i.e, the decrypted session between the SSL card and real
server are not sticking together.. I am not
sure if this is supported in the first place.., Can someone confirm this please..? and you if you have some working configuration, please share..

Btw, I am looking for a CSM-S config, but a CSM with SSLM config will help as well..
Thanks

Similar Messages

Trying to understand SSL sticky with CSS 11506 / ssl-l4-fallback behavior

Dear experts
I have a CSS 11506 (v7.50) which is used to load balance several SSL-based sites. We use the following textbook content rule:
content mysite-SSL
vip address 10.0.0.1
add service s01
add service s02
add service s03
port 443
protocol tcp
advanced-balance ssl
application ssl
flow-timeout-multiplier 225
active
If I read the manual correctly, SSL L3 session IDs are going to be used till a flow is set up. Then the ssl-l4-fallback (it is enabled) directive kicks in and load balancing is done based on the source IP, destination port.
However, my stats show:
Sticky Statistics - SFM Slot 1, Subslot 1:
Total number of new sticky entries is 4937735
Total number of sticky table hits is 33476045
Total number of sticky rejects (no entry) is 0
Total number of sticky collision is 0
Total number of available sticky entries is 0
Total number of used sticky entries is 131071
Total L3 sticky entries are 131
Total L4 sticky entries are 0
Total SSL sticky entries are 130940
Total WAP sticky entries are 0
Total number of SIPCID sticky entries is 0
So, why don't I see anything in the L4 sticky entries?
Also, I would expect that once the ssl-l4-fallback kicks in, a client will be always directed to the same server (since the CSS uses now source IP, dest port for load balancing). However, if I close and start again my browser I hit a different server.
Your thoughts and suggestions are highly appreciated.
John.

Hi Gilles
Thank you for your response. If I may ask the group for a final further clarification, so as to put this matter to rest. Since there are a lot of frames transmitted in either direction, I would expect the following to be happening and overriding the use of SSLv3 session IDs. Following is the section of the manual that seems to contradict what you say (and I see on the stats). Am I reading the manual wrong?
"Cisco Content Services Switch
Content Load-Balancing
Configuration Guide
Software Version 8.20
November 2006
page 11-14
Configuring SSL-Layer 4 Fallback
Insertion of the Layer 4 hash value into the sticky table occurs when more than
three frames are transmitted in either direction (client-to-server, server-to-client)
or if SSL version 2 is in use on the network. If either condition occurs, the CSS
inserts the Layer 4 hash value into the sticky table, overriding the further use of
the SSL version 3 session ID."

The SSL support feature is not properly configured. Https is not available.

Hi all
We get the following warning message even though we are not using SSL.
"The SSL support feature is not properly configured. Https is not available."
I tried with the following parameter set to false in the MobileEngine.config, still the same warning occurs for each synchronization done. But the sync works fine.
MobileEngine.Security.SSLSupport=false
Had any body come accross this one, if so please let me know.
Thanks
Raj

Hi Raj
The error "The SSL support feature is not properly configured. Https is not available" will not cause any problems for you during synchronization. The reason that this error is displayed is due to the fact that by default MI is configured to support HTTPS Synchronization and not HTTP. This is because it is recommeded to use HTTPS sync inorder to transmit data in a secure manner and this is very necessary in customer production system. This so called error will not have any impact on sync but is just an information to the administrator. This can be disabled by the use of parameter <b><i>MobileEngine.Security.SSLSupport=false</i></b> but make sure that this parameter is set to false even before performing the first sync i.e before obtaining a device id. If you set this value to false after performing some syncs, the error is still visibile in either the Web Console or the NetWeaver Administrator because it would have been sent by the previous sync and these statments are retained and never purged. Hope this helps and clarifies your doubts.
Best Regards
Sivakumar

CSS - SSL Stickiness

Gilles,
Could you please advice the CSS content configured with stickiness SSL ID and balance method round robin is recommended configuration or not.Are there are any issues with SSL stickiness with the browsers i.e IE .
Note:- I am not using SSL Module in the CSS.
Thanks in advance...

There are two issues
Some versions of IE (5.0, 5.5 --check http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q265369) will
cause the client to change its SSL ID every 2 minutes and this will break
stickyness with application ssl and advanced balance SSL as this is layer 5
stickyness based on SSL session ID. A sniffer trace from the client will
show the ID field change.
You have to be aware that SSL stickiness will only work with SSL v3,
because it comes with the session ID not encrypted. SSL v2 comes with the session ID encrypted and you can't do stickyness
based on that version.So your appliaction servers must be using SSL v3, if you want to use SSL ID based stickiness.
Hope it helps
Syed Iftekhar Ahmed

ACE SSL Sticky class-map generic vs class default differences.

There was a thread recently titled "ACE 3.0(0) SW / LB with SSL Session-ID" where Giles Dufour outlined a configuration for an ACE performing sticky based on SSL Session ID.
Can anyone explain the benefits and differences of using a specific class-map generic such as this:
class-map type generic match-any SSL-v3-32
2 match layer4-payload regex "\x16\x03\x00..\x01.*"
3 match layer4-payload regex "\x16\x03\x01..\x01.*"
Versus just matching class default?
So if I have a configuration such as this:
policy-map type loadbalance generic first-match SSL-v3-Sticky
class SSL-v3-32
sticky-serverfarm ssl-v3
vs
policy-map type loadbalance generic first-match SSL-v3-Sticky
class class-default
sticky-serverfarm ssl-v3
What's the benefit or drawback?

The SSL session id is only available in version 3.0.1 and 3.1.1
So you can match this particular version and then attempt to do stickyness.
You are guaranteed to find what you're looking for.
If you match a class-default it means you apply stickyness to any version of ssl packet.
So there is a risk to misinterpret the content of the packet and stick on something else than the session id.
Gilles.

11503 Loadbalance SSL sticky and HTTP not sticky to proxy-cache

I am using a 11503 to balance 200 schools traffic to 5 caches. Some of the schools have firewalls so the CSS sees their PCs as coming from a single IP. If I set the rule to balance sticky then the load is not spread evenly to the 5 proxies causing them to get overloaded from time to time.
If I balance the load non-sticky (say leastconn) then users have trouble accessing certain SSL sites.
Does anyone know a good solution for this?

Hi Joerg,
Thanks for your reply. How would you code your solution? Currently I am using the following to work around particular sites:
service Proxy1
ip address 10.0.0.11
type proxy-cache
active
service Proxy2 ... etc
**************************** DQL ****************************
dql domains-no-balance
domain www.dontbalancethissite.com
domain ... etc
!*************************** OWNER ***************************
owner admin
content Proxy-servers
add service Proxy1
add service Proxy2
add service Proxy3
add service Proxy4
add service Proxy5
protocol tcp
port 3128
vip address 10.0.0.100
sticky-inact-timeout 5
balance leastconn
active
content no-load-balance
vip address 10.0.0.100
advanced-balance sticky-srcip
balance leastconn
add service Proxy1
add service Proxy2
add service Proxy3
add service Proxy4
add service Proxy5
protocol tcp
port 3128
url "/*" dql domains-no-balance
sticky-inact-timeout 5
Regards,
Ben

HTTP & SSL Stickiness

The website we're load-balancing with our CSS 11150 is an e-commerce site that will redirect the user to a SSL page which resides on the same server upon checkout. I was attempting to follow the tutorial given by this link (http://www.cisco.com/warp/public/117/converting_ssl_http.html ), but didn't quite understand the example given. More specifically, the page says:
"During the client's session, the transition is made to SSL port 443. This causes a new content rule to be hit and the client is load-balanced to another server. To prevent this from occurring, configure an HREF pointing the server back to itself:"
"<A HREF=https://ip_address/path> secure site </A>"
The PDF version of the document uses this URL:
"http://kbase.cisco.com/paws_data/16202/<A HREF="javascript:newWin('https://ip_address/path')>secure site</A>"
Besides the confusion that these conflicting results produce, I'm still not sure exactly what the URL is referencing.
An example of our setup is as follows:
(Public)
Arrowpoint IP: 123.123.123.215
Arrowpoint VIP: 123.123.123.220
(Private)
Arrowpoint IP: 10.0.0.1
WS-1: 10.0.0.2
WS-2: 10.0.0.3
Domain Name: http://www.our-domain.com
Based on this information, how would I construct the URL I would need to embed within our webpage in order to convert a HTTP session to SSL and stay stuck?
Thanks,
Andy

In regards to my last post, here's our current setup:
!*************************** GLOBAL ***************************
bridge spanning-tree disabled
restrict telnet
ip route 0.0.0.0 0.0.0.0 10.0.0.1 1
!************************* INTERFACE *************************
interface e2
bridge vlan 2
interface e3
bridge vlan 2
!************************** CIRCUIT **************************
circuit VLAN1
description "External"
ip address 10.0.0.33 255.255.255.0
circuit VLAN2
description "Internal"
ip address 172.20.0.1 255.255.255.0
!************************** SERVICE **************************
service ws-1
ip address 172.20.0.31
protocol tcp
active
service ws-2
ip address 172.20.0.32
protocol tcp
active
!*************************** OWNER ***************************
owner arrowpoint
content vip-arrowpoint
protocol tcp
port 80
vip address 10.0.0.30
add service ws-1
add service ws-2
advanced-balance sticky-srcip
active
content ws-1-ssl
protocol tcp
port 443
vip address 10.0.0.31
add service ws-1
advanced-balance sticky-srcip
active
content ws-2-ssl
protocol tcp
port 443
add service ws-2
vip address 10.0.0.32
advanced-balance sticky-srcip
active
!*************************** GROUP ***************************
group arrowpoint
add service ws-1
add service ws-2
vip address 10.0.0.30
active

SSL CSM Sticky

Hi,
My setup is as follow, I have 2 CSM in two different 6509 running in active and standby mode and 2 SSLM running also in two different 6509 too.
My SSL traffic terminates at my SSLM
Currently my CSM and SSL is working fine but I notice there's this niggling issue whereby at times accessing my web servers via HTTPS traffic. My SSL stickyness don't seem to be working at times. The secnario is as that while accessing the pages via HTTPS the certificate web pages keep prompting and after checking the cert there are from 2 different SSLM. Furthermore after doing a trace I can confirm that the SSL sticky don work at times but this is like a 5-10 % rate.
After reading some of the post in the forum, the SSL ID in IE will expire and renegoiate again. Could this cause this problem ? ALso how can I rectify this. Pls advise. Thanks
Attached are my config and the screen cature of the error

indeed IE is most probably the culprit here.
The CSM learns the SSLID generated by the SSLM and create a sticky entry to link this value to the SSLM.
when IE wants to renegotiate the SSLID, it starts a new SSL session with a blank [0x00] SSLID.
The CSM can't stick this client to the corresponding SSLM and therefore it will loadbalance the session to the next SSLM.
If you have no control on the browser, there is no solution using SSLID.
What some people will do is use another form of stickyness to resolve the problem.
The only other sticky method is based on source ip address.
Regards,
Gilles.

ACE 4710 SSL server LB with stickiness

I will be replacing 11500 CSS which are not doing SSL termination, just load-balancing SSL sessions terminated on servers with ACE 4710.
On their CSS config, they were doing SSL-sticky. I understand the 4710 doesn't support SSL sticky, but can perform the same function by parsing the HTTP header. Has anyone done this config before and know where/how to parse the header to look for the SSL session# and stick connections to same server?
THANKS!

In Ace 2.x code GPP (Generic protocol parsing) was introduced that enables ACE to look into the Layer 4 payload.Which is how this stickiness id achieved.
details at
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A2/configuration/slb/guide/sticky.html#wp1133923
I dont think its currently available on ACE appliance yet.
Syed

HTTPS persistence SSL session, ACN 4.2.1

Customer is experiencing a problem resulting in the ACN software resolving the host.domain.com twice. Webapplication https://host.domain.com/webapp/index.jsp. The customer uses a ACN to proxy the https request. The host.domain gets resolve to 1 of 4 available application servers (webserver). At the application login page (index.jsp) the user is successfully authenticated by the application's Login servlet on webserver 1. The user is then redirected to the select application, local to the webserver 1. It appears that when the ACN receives the response from webserver 1 with the fully qualitfying URL. The redirection cause the ACN to resolve the host.domain against DNS and as a result, the user's browser is redirected to a different webserver. The users previous session is no longer valid, breaking the client/webserver trusted relationship
If the above user uses 1 of the 4 available IP address on the DNS entry, the users successfully maintains the SSL session. The customer is migrating to a Cisco Content Engine 560 running version 4.2.1 ACN software.
I understand there are ACN features that could effect the HTTP session persistence/SSL trust. The services/features include boomerang, Reverse Proxy, content balancing. I request information on the service or feature of the ACN that could cause the problem I speak of from above.
I understand there are different methods of implementing session persistence, like sticky session and SSL sticky, but believe the ACN does provide this feature.

The customer is experiencing network issues when attempting to access our application. The customer is experiencing has been seen with a previous customers that had a similar network devices.
The customer uses a Cisco Content Engine CE-560 with Application and Content Networking Software (ACNS) version 4.2.1. The problem seems to a result of the ACNS resolving the hostname.domain.com twice. The webserver's DNS (hostname.domain.com) entry resolves to one of four available webservers (DNS round robining).
nslookup hostname.domain.com
webserver1 webserver2 webserver3 webserver4
nslookup hostname.domain.com
webserver2 webserver3 webserver4 webserver1
and so on.
All client/webserver communication is through SSL. When the customer uses the FQDN URL (https://hostname.domain.com/webapp/index.jsp) to access the application login page, the server portion of the URL is resolved to webserver1. At this time, the customer has an established HTTPS session with webserver1. Once a login servlet running on webserver1, receives the customer supplied login credentials, the servlet sends a server response 302 redirecting the customer to the selected application.
This redirection response seems to cause the ACNS to resolve the hostname.domain.com and as a result, the customer's browser is redirected to a different webserver, webserver2. The users previous session is no longer valid, causing the application to generate a false inactivity timeout.
If the customer sends a HTTPS request using anyone of the four IP address from DNS, the session is maintained and the customer does not receive the false inactivity timeout, because the session is not "broken".
The customer is migrating off of a Netscape (iPlanet) Web Proxy solution and does not experience the problem accessing the application, using the FQDN URL.
DNS caching is enabled on the customer CE.

Sticky assistance please!

Dear Netprof,
Im having problems with maintaining sticky sessions on the ssl proxy feature of my 11501 content switch.
Ive seemed to have managed to get the 11501 to stick to one web server whilst using ssl, but had to modify the content L3_Rule to balance on src address. And this seems to have slowed down all access both http & https through the 11501.
I also now seem to be both sticky in both http & https, can anyone help me here, what I want is just sticky in ssl (https) and load balance in http.
Thanks in advance, config below;
Regards, Adrian.
CSS11501# sh run
!Generated on 26/05/2006 16:05:40
!Active version: sg0810002
configure
!*************************** GLOBAL ***************************
date european-date
ssl associate rsakey TESTrsakey TESTrsakeyfile1
ssl associate cert TESTrsacert TESTSSLcertfile.pem
ftp-record ftpserv 192.168.68.189 anonymous des-password xx /outgoing
ip route 0.0.0.0 0.0.0.0 192.168.68.161 1
!************************** CIRCUIT **************************
circuit VLAN1
ip address 192.168.68.171 255.255.255.240
!*********************** SSL PROXY LIST ***********************
ssl-proxy-list ssl_list1
ssl-server 20
ssl-server 20 vip address 192.168.68.174
ssl-server 20 rsakey TESTrsakey
ssl-server 20 rsacert TESTrsacert
ssl-server 20 cipher rsa-with-rc4-128-md5 192.168.68.174 8080 weight 5
active
!************************** SERVICE **************************
service TEST-GR4-WEB01
ip address 192.168.68.173
active
service TEST-GR4-WEB02
ip address 192.168.68.172
active
service ssl_serv1
type ssl-accel
slot 2
keepalive type none
add ssl-proxy-list ssl_list1
active
!*************************** OWNER ***************************
owner L5_Owner
content L3_Rule
add service TEST-GR4-WEB01
add service TEST-GR4-WEB02
vip address 192.168.68.174
balance srcip
active
content L5_Rule
add service TEST-GR4-WEB01
add service TEST-GR4-WEB02
vip address 192.168.68.174
protocol tcp
port 80
url "/*"
balance aca
active
owner ssl_owner
content ssl_rule1
vip address 192.168.68.174
protocol tcp
port 443
application ssl
add service ssl_serv1
active
CSS11501#

Try using the L3 content rule .

Can't get sticky load balancing to work

I'm really puzzled why sticky LB is not working for a simple case I'm trying. I have two simple JSP's, both registered (see web.xml and ias-web.xml below). I'm using lite session and set distributable to false. Just in case someone can tell by just looking at my session id if it's supposed to be sticky or not, it looks like following -
GXLiteSessionID-4818869464307751325
My two JSP's are also attached below, and they're pretty simple. A new session is supposed to be created in login page and clicking on the logout page invalidates the session.
What I see is that each request (whether login or logout) is randomly sent to any server. For example, if I go to login once, further request to login or logout (whether through refresh or by clicking on the link) is not necessarily sent to the same server.
Any idea what's missing in my setup? I've tried different types of load balancing (round robin, etc.) so I know that's not it.
Thanks a lot in advance.
Jitu
-----web.xml-------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN' 'http://java.sun.com/j2ee/dtds/web-app_2_2.dtd'>
<web-app>
<display-name>WebDesk</display-name>
<distributable>false</distributable>
<servlet>
<servlet-name>TestLogin.jsp</servlet-name>
<jsp-file>TestLogin.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>TestLogin.jsp</servlet-name>
<url-pattern>TestLogin.jsp</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>TestLogout.jsp</servlet-name>
<jsp-file>TestLogout.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>TestLogout.jsp</servlet-name>
<url-pattern>TestLogout.jsp</url-pattern>
</servlet-mapping>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name></realm-name>
<form-login-config>
<form-login-page></form-login-page>
<form-error-page></form-error-page>
</form-login-config>
</login-config>
</web-app>
-----ias-web.xml------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ias-web-app PUBLIC '-//Sun Microsystems, Inc.//DTD iAS Web Application 1.0//EN' 'http://developer.iplanet.com/appserver/dtds/IASWebApp_1_0.dtd'>
<ias-web-app>
<servlet>
<servlet-name>TestLogin.jsp</servlet-name>
<guid>{A6D6B277-288D-1C22-C3CA-0800209A2F7C}</guid>
<servlet-info>
<sticky>true</sticky>
<sticky-lb>true</sticky-lb>
</servlet-info>
</servlet>
<servlet>
<servlet-name>TestLogout.jsp</servlet-name>
<guid>{B88B7D19-28B9-1C22-EE63-0800209A2F7C}</guid>
<servlet-info>
<sticky>true</sticky>
<sticky-lb>true</sticky-lb>
</servlet-info>
</servlet>
<session-info>
<impl>lite</impl>
<timeout-type>last-access</timeout-type>
<timeout>60</timeout>
<secure>false</secure>
<domain></domain>
<path>/</path>
<scope></scope>
</session-info>
</ias-web-app>
-----TestLogin.jsp-------
<%
     java.util.Date date = new java.util.Date();
     HttpSession sess = request.getSession(true);
     System.out.println(date + ":TestLogin.jsp: sessionid = " + sess.getId() + ", new = " + sess.isNew());
%>
<HTML>
<HEAD>
<TITLE>TestLogin</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" topmargin=0 leftmargin=0 marginwidth=0 marginheight=0>
<p>
You are now logged in.<br>
<br>
TestLogin.jsp: sessionid = <%=sess.getId()%>, new = <%=sess.isNew()%><br>
<br>
Click here to logout.
</BODY>
</HTML>
----TestLogout.jsp-------
<%
     java.util.Date date = new java.util.Date();
     HttpSession sess = request.getSession(true);
     System.out.println(date + ":TestLogout.jsp: sessionid = " + sess.getId() + ", new = " + sess.isNew());
%>
<HTML>
<HEAD>
<TITLE>TestLogout</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" topmargin=0 leftmargin=0 marginwidth=0 marginheight=0>
<p>
TestLogout.jsp: sessionid = <%=sess.getId()%>, new = <%=sess.isNew()%><br>
<br>
<%
sess.invalidate();
%>
You are now logged out.<br>
<br>
Click here to login.
</BODY>
</HTML>

Hi,
I think it's best to wait for sometime and check the behaviour of sticky load balancing for sometime, the reason being one or more of the following...
- Although sticky feature ensures that the component is run at a single server, when combined with load balancing and under heavy user loads, the load balancing takes place.
- If we rule out the previous case, then, the load balancing mechanism, especially, per component based or per server based, sends request by round robin technique initally(around 128 times or so) and then calculates the effeciency of the response time and then follows the per server based or per component based.
- Meanwhile please ensure that, you have enabled the Sticky LB option under Application using iASAT and please wait for sometime sending requests(probably 130 times) after which it's good to check the mechanism of the sticky bit technique. If it doesn't behaves as it has to then, please let me know and I can help you further on this.
Regards
RG

RPC Load Balancing on CSM and SSL

We are load-balancing SSL successfully but the Exchange people want to use RPC to access
mailboxes using CSM.
We need to allow ports 6005 through 59530 used by the Client Access Servers. Any suggestions?

Thanks. I tried that, but according to our exchange administrators, the solution didn't work. Here is my configuration:
serverfarm EXCH-CAS
nat server
no nat client
real x.x.248.100
inservice
real x.x.248.101
inservice
probe EXCH-CAS
serverfarm EXCH-CAS-SSL
nat server
no nat client
real x.x.254.60
inservice
real x.x.254.61
inservice
probe SSL-FARM
! vserver EXCH-CAS
virtual x.x.254.154 tcp www
vlan 460
serverfarm EXCH-CAS
sticky 1440 group 152
replicate csrp sticky
replicate csrp connection
persistent rebalance
inservice
vserver EXCH-CAS-S
virtual x.x.214.139 tcp https
vlan 400
serverfarm EXCH-CAS-SSL
sticky 5 group 252
replicate csrp sticky
replicate csrp connection
persistent rebalance
inservice
vserver EXCH-CAS-TEST-S
virtual x.x.214.139 tcp 0
vlan 400
serverfarm EXCH-CAS
sticky 5 group 252
replicate csrp sticky
replicate csrp connection
persistent rebalance
inservice
Thanks,
Mohamad

Cookie stickiness configuration issue with Cisco ACE

Hi,
We have configured a ACE (in standby mode) with ip netmask stickiness and wanted to configure cookie stickiness for a remedy server placed behind the ace. BMC has said that they use JSESSIONID field on the remedy application and i want to know the procedure for configuring ace to see this field and deploy cookie stickiness feature on the ace.
We tried configuring the ace to learn the cookie string dynamically and tried to insert the cookie in the server response to the client but both methods have failed and the user is not able to see the remedy app webpage in both occassions.
Are there any pre-requisites to be configured on the ace before configuring cookie stickiness feature? We would appreciate your timely response.
Thanks in advance.

Hi,
Refer the document below for sample configuration. If this still doesn't work a full config and sniffer capture required to verify this.
http://docwiki.cisco.com/wiki/Session_Persistence_Using_Cookie_Learning_on_the_Cisco_Application_Control_Engine_Configuration_Example
Regards,
Siva

Consuming a Web Service via SSL with Basic Authentication

Hello,
I have a simple web service (returns a parameter value) and want to consume it. Therefore I have generated a proxy for its in Netweaver Studio SP13.
When I set up the web service to be accessed via HTTP and Basic Authentication (Username/Password), everything is fine. When I set up the web service to communicate via HTTPS, I get the following error message in my client:
java.rmi.RemoteException: Service call exception; nested exception is:
     java.lang.NullPointerException
     at priv.senw04.wsproxy.multisec_ssl.SSLBindingStub.pingText(SSLBindingStub.java:87)
     at priv.senw04.wsproxy.multisec_ssl.SSLBindingStub.pingText(SSLBindingStub.java:96)
     at priv.se.wsclient.MultiSecSSL.main(MultiSecSSL.java:38)
Caused by: java.lang.NullPointerException
     at com.sap.engine.services.webservices.jaxm.soap.HTTPSocket.disconnect(HTTPSocket.java:625)
     at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.HTTPTransport.closeSession(HTTPTransport.java:396)
     at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.call(MimeHttpBinding.java:1312)
     at priv.senw04.wsproxy.multisec_ssl.SSLBindingStub.pingText(SSLBindingStub.java:80)
     ... 2 more
Testing the web service with WebServiceNavigator and/or by using a generated WebDynpro Client results in the following error:
000D604C66BE004E0000001300000AFC00040922E0160632 : An error occurred during processing the timestamp. The error was: com.sap.security.core.ws.wss.NoSecurityHeaderException No wsse:Security header has been defined for role soap:finalActor. Please verify the policy configuration..
But my main focus is on the client implementation based on a proxy. Here comes the client's code:
public class MultiSecSSL {
    public static void main(String[] args) {
        try {
            MultiSecuritySSLAuthImpl serviceInterface = new MultiSecuritySSLAuthImpl();
            SSLBindingStub service = (SSLBindingStub)serviceInterface.getLogicalPort(MultiSecuritySSLAuthViDocument.class);
            SecurityProtocol protocol = (SecurityProtocol) service._getGlobalProtocols().getProtocol("SecurityProtocol");
            AuthenticationContext auth = protocol.getAuthenticationContext();
            auth.setIgnoreSSLServerCertificate(true);
            auth.setUsername("cfpcompany");
            auth.setPassword("demo");
            String ret = service.pingText("Called service MultiSecurity via SSL");
            System.out.println(ret);
        } catch (Exception e) {
             e.printStackTrace(System.out);
Here comes the logical port information of the generated proxy:
<?xml version="1.0" encoding="UTF-8"?>
<LogicalPorts Name='MultiSecuritySSLAuth' InterfaceName='priv.senw04.wsproxy.multisec_ssl.MultiSecuritySSLAuth'>
<LogicalPort Name='SSLPort_Document' Endpoint='https://192.168.129.76:50001/MultiSecuritySSLAuth/SSL?style=document' BindingName='SSLBinding' BindingUri='urn:MultiSecuritySSLAuthWsd/SSL/document' BindingImplementation='SOAP 1.1 HTTP Binding with Attachments' StubName='priv.senw04.wsproxy.multisec_ssl.SSLBindingStub' Default='true' InterfaceName='priv.senw04.wsproxy.multisec_ssl.MultiSecuritySSLAuthViDocument' Original='true' Valid='true'>
    <globalFeatures>
      <Feature Name='http://www.sap.com/webas/630/soap/features/headers/' Provider='SoapHeadersProtocol' Original='false'>
      </Feature>
      <Feature Name='http://www.sap.com/webas/630/soap/features/session/' Provider='SessionProtocol' Original='false'>
        <Property Name='SessionMethod' Value='httpCookies'>
        </Property>
      </Feature>
      <Feature Name='http://www.sap.com/webas/630/soap/features/authentication' Provider='SecurityProtocol' Original='true'>
        <Property Name='AuthenticationLevel' Value='None'>
        </Property>
        <Property Name='AuthenticationMechanism' Value='HTTP'>
        </Property>
        <Property Name='AuthenticationMethod' Value='BasicAuth'>
        </Property>
        <Property Name='SupportsSSO2Authentication' Value='false'>
        </Property>
      </Feature>
      <Feature Name='http://www.sap.com/webas/630/soap/features/transportguarantee' Original='true'>
        <Property Name='Level' Value='No'>
        </Property>
        <Property Name='TLSType' Value='SSL'>
        </Property>
      </Feature>
    </globalFeatures>
    <localFeatures>
      <Operation Name='pingText'>
        <Feature Name='http://www.sap.com/webas/630/soap/features/wss' Original='true'>
          <Property Name='RequestPolicy' Value='Signature'>
          </Property>
          <Property Name='ResponsePolicy' Value='None'>
          </Property>
        </Feature>
        <Feature Name='http://sap.com/webservices/authorization' Original='true'>
        </Feature>
      </Operation>
    </localFeatures>
</LogicalPort>
</LogicalPorts>
To me, this looks consistent. Any idea, what is misconfigured on my machine ?

Hi Martin,
that is exactly, what I did.
- Change Web Service Configuration in IDE
- Build and Deploy the Service to my local Server
- Check Service in Visual Administrator
- Deleted and Regenerated the Standalone Proxy
- Deleted and Recreated the link between CLient and Proxy Project in IDE
- Started Client
Here comes the section of the ws-deployment-descriptor.xml of the service. For me, it matches, what the proxy generated.
<webservice>
    <guid>ed8363_10876a54b6d__7fe9_192_168_129_76_1135862193037</guid>
    <ejb-name-temp>MultiSecWSBean</ejb-name-temp>
    <webservice-name>
      <namespaceURI>urn:MultiSecuritySSLAuthWsd</namespaceURI>
      <localName>MultiSecuritySSLAuth</localName>
    </webservice-name>
    <webservice-internal-name>MultiSecuritySSLAuth</webservice-internal-name>
    <standard-namespaceURI>urn:MultiSecuritySSLAuthWsd</standard-namespaceURI>
    <ws-configuration>
      <configuration-name>SSL</configuration-name>
      <ejb-name>MultiSecWSBean</ejb-name>
      <service-endpoint-name>
        <namespaceURI>urn:MultiSecuritySSLAuthWsd</namespaceURI>
        <localName>SSLPort</localName>
      </service-endpoint-name>
      <wsdl-porttype-name>
        <namespaceURI>urn:MultiSecuritySSLAuthWsd</namespaceURI>
        <localName>MultiSecuritySSLAuthVi</localName>
      </wsdl-porttype-name>
      <webservice-definition-ref>
        <package>com.technidata.cfp.i3rdparty.cfpxml</package>
        <name>MultiSecuritySSLAuthWsd.wsdef</name>
      </webservice-definition-ref>
      <service-endpoint-vi-ref>
        <package>com.technidata.cfp.i3rdparty.cfpxml</package>
        <name>MultiSecuritySSLAuthVi.videf</name>
      </service-endpoint-vi-ref>
      <transport-binding name="SOAPHTTP_TransportBinding">
        <wsdl-binding-name>
          <namespaceURI>urn:MultiSecuritySSLAuthWsd</namespaceURI>
          <localName>SSLBinding</localName>
        </wsdl-binding-name>
      </transport-binding>
      <transport-address>/MultiSecuritySSLAuth/SSL</transport-address>
      <global-features>
        <feature name="http://www.sap.com/webas/630/soap/features/transportguarantee" protocol="SecurityProtocol">
          <property name="TLSType" value="SSL"/>
        </feature>
        <feature name="http://www.sap.com/webas/630/soap/features/authorization" protocol="SecurityProtocol"/>
        <feature name="http://www.sap.com/webas/630/soap/features/authentication" protocol="SecurityProtocol">
          <property name="AuthenticationMethod" value="BasicAuth"/>
          <property name="AuthenticationMechanism" value="HTTP"/>
          <property name="SupportsSSO2Authentication" value="false"/>
        </feature>
      </global-features>
      <operation-configuration uniqueViName="pingText(java.lang.String)">
        <transport-binding-configuration>
          <input>
            <property name="soapAction" value=""/>
            <property name="encodingStyle" value="http://schemas.xmlsoap.org/soap/encoding/"/>
          </input>
          <output>
            <property name="encodingStyle" value="http://schemas.xmlsoap.org/soap/encoding/"/>
          </output>
        </transport-binding-configuration>
        <feature name="http://www.sap.com/webas/630/soap/features/wss" protocol="SecurityProtocol">
          <property name="RequestPolicy" value="None"/>
          <property name="ResponsePolicy" value="None"/>
        </feature>
        <feature name="http://sap.com/webservices/authorization" protocol="SecurityProtocol">
          <property name="security-roles">
            <property name="role1" value="use_multisec_service"/>
          </property>
        </feature>
      </operation-configuration>
    </ws-configuration>
</webservice>
Regards,
Stefan

SSL Sticky feature...

Similar Messages

Maybe you are looking for