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

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

Question on CSS cookie sticky

Hi everyone,
I have a question about CSS cookie sticky.
- Server issues the following cookie string to the client and it is fixed to 18 bytes.
Set-Cookie: JSESSIONID=aaabbbcccdddeeefff; path=/
- Client embedded the following cookie string in the subsequent HTTP header.
Cookie: xx_user_id=ZZZZ03; com.dummy.xyz.session.cookie=|user|pc|ja|Shift_JIS|default||yellow|/oooo/default.portal|; JSESSIONID=aaabbbcccdddeeefff
* Note that I made cookie information suitable as example.
There is the cookie string (JSESSIONID=aaabbbcccdddeeefff) issued by Server in the HTTP header from client but that cookie string (JSESSIONID=aaabbbcccdddeeefff) is located following the cookie string that the client made by oneself at the end of cookie string. And the cookie string and the length of cookie string that client made by oneself might change so the total length of cookie string also might change. It means I can not clarify the total length of the cookie string.
In this situation, I want CSS to stick with cookie string "JSESSIONID=aaabbbcccdddeeefff".
The characters of string located following the "JSESSIONID=" (in this case, "aaabbbcccdddeeefff") might change but it is fixed to 18 bytes. The total length of cookie string is 141 bytes in above mentioned example.
So I informed customer to configure the following parameters to get CSS done cookie sticky for above mentioned cookie string. CSS software version is sg0750303.
owner test
content testsv-tcp80
add service testsv1-tcp80
add service testsv2-tcp80
advanced-balance cookie
　string range 1 to 200
string process-length 18
url "/*"
redundant-index 1001
protocol tcp
port 80
vip address xxx.xxx.xxx.xxx
active
However CSS was not able to treat the above mentioned cookie correctly which means the subsequent HTTP request was not stuck (persisted) to same server.
I do not understand why CSS cookie sticky did not work correctly with this configuration.
Then customer configured CSS with the following parameters to get CSS inserted cookie string and, of course, the result is OK that is CSS could stick the connection to same server.
owner test
content testsv-tcp80
add service testsv1-tcp80
add service testsv2-tcp80
advanced-balance arrowpoint-cookie
url "/*"
redundant-index 1001
protocol tcp
port 80
vip address xxx.xxx.xxx.xxx
active
Has anybody experienced similar thing ?
Could you please let me know if you have any comment, information
Your information would be appreciated.
Best regards,

the CSS does not learn dynamic cookie.
You can match a fixed string inside a cookie and pre-define which server to use with that specific string.
That's why your solution did not work.
Arrowpoint-cookie is a better solution and easier to implement.
Gilles.

CSS/SSL termination - cypher negotiation Q

Hi everyone
question regarding SSL termination on CSS/SSL module.
I have several several cyphers in my ssl-proxy list,
What is the algorithm to choose the cypher ?
I may assume that CSS and browser negotiate it during SSL session establishing.
The testing shows that same browser gets different cyphers when it hits
different CSSs (cyphers are in the same order in proxy-lists on CSSs)
Thanks
Alex

Alex,
it's not really an algorithm.
The browser selects the first cipher that matches its requirements in the list presented by the server/CSS.
The CSS builds a list in the order of weight.
If you did not specify any weight, the list can be random depending in which order you entered the command.
I would say, if you want a specific cipher to be selected, use a highest weight for this cipher.
Gilles.

How many CSS SSL certificates needed?

From reading the CSS SSL Configuration Guide, it seems that one certificate is needed for each virtual SSL server (or VIP), regardless of how many servers are being load-balanced behind that VIP, but that is not made very clear. Also, it appears that a separate certificate is required for each virtual SSL server. Can someone please confirm or correct this for me? Thank You.

A quick (I hope) follow-up question on this...
Given multiple domain names being load-balanced by a CSS with a single SSL module, would I need different key and cert associations? I am thinking of something like this:
ssl associate rsakey prodkey prodkey.pem
ssl associate cert prodcert prodcert.pem
ssl associate dhparam proddh proddh.pem
ssl associate rsakey intkey intkey.pem
ssl associate cert intcert intcert.pem
ssl associate dhparam intdh intdh.pem

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

CSS restore sticky ssl

Hi everyone,
I am facing a strange issue. I have a SSLv3 service running on two servers behind a pair of(active-standby) CSS 11501, wich do advance-balance ssl. Few days ago I noticed that the CSS stopped the LB and start sending he request to only one server( both alive). I think that is hapening due to the SSL-layer 4 fallback. How do I verify it , and restore stickyness with session ID?
Thanks in advance
David

Further observations:
issueing the commnd ssl-l4-fallback disable, restores the load balance. This means, I think, that the l4-fallback was activated. The questions remaiins, why, if we are using ssl v3? why the l4 sticky table has no entries. Here is a ssldump example:
New TCP connection #2: 172.16.20.1(46311) <-> 172.26.80.1(3034)
2 1 0.0011 (0.0011) C>SV3.0(95) Handshake
ClientHello
Version 3.0
random[32]=
46 8a 31 6f 87 94 35 a8 30 16 42 5e e9 6e 31 c0
d6 17 ac eb 92 9c 53 db 85 92 df 30 0e 67 90 90
cipher suites
Unknown value 0x39
Unknown value 0x38
Unknown value 0x35
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
Unknown value 0x33
Unknown value 0x32
Unknown value 0x2f
SSL_DHE_DSS_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_RC2_56_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_MD5
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5
compression methods
NULL
2 2 0.0025 (0.0014) S>CV3.0(74) Handshake
ServerHello
Version 3.0
random[32]=
46 8a 19 d6 a8 f5 88 8e d4 d5 16 06 df 1e 8e e5
0e 7c 1b f2 f8 bb b9 c8 7d c6 e2 f8 fe e6 7f b0
session_id[32]=
db 23 61 fa 35 5a ef 0e da 3d be b0 c2 85 39 9f
4d b1 75 5d 5b ef c8 46 bc 4d db ab 31 23 d6 d4
cipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA
compressionMethod NULL
2 3 0.0025 (0.0000) S>CV3.0(1147) Handshake
Certificate
2 4 0.0025 (0.0000) S>CV3.0(4) Handshake
ServerHelloDone
2 5 0.2346 (0.2320) C>SV3.0(260) Handshake
ClientKeyExchange
EncryptedPreMasterSecret[256]=
1b a5 47 46 7b 9a 8b 84 88 d4 54 ba 23 c7 7a 31
db 8a 74 c2 02 3b 8b 50 75 c3 c8 c0 38 4c 18 e8
0a e8 c8 47 39 ff 9b 3c 6a cc d3 21 78 69 e6 50
88 55 e8 b3 d3 b1 2a 04 b3 ba 66 e4 c8 49 f4 8e
a0 bd 74 60 e9 f2 0c a1 25 47 03 4e 6c ed 96 52
de 2a 9a 60 29 c5 f6 21 c8 3e 58 ef af 3f 12 b2
ee 34 c0 70 12 d0 64 30 28 65 ed fb ff 65 f2 de
d0 bf cd e6 26 79 6f 3c 61 5f df da bf ac 4a cf
4c 0e 0c 66 44 e1 b2 a3 34 f2 27 75 f0 e4 e7 a4
48 06 76 93 73 0d 09 75 35 ea a1 91 d9 c8 ad 58
b9 1f 45 bf c6 09 61 cb 2d 75 4a ba ed 45 15 44
0f fc 9e 5b 90 e7 b2 86 15 1c 43 a5 52 0d c7 1e
d8 81 42 db 77 35 99 4d 0d 5b 20 e6 dd c5 a1 7d
64 9a 13 d2 99 b7 1d 94 a7 fe ce b6 67 7d df b9
25 fb 27 d2 6e 90 49 54 b9 c1 10 32 eb 42 df 43
b6 1c 94 4e ee 0b ca 29 27 8a 3d b8 fe 59 00 f4
2 6 0.2346 (0.0000) C>SV3.0(1) ChangeCipherSpec
2 7 0.2346 (0.0000) C>SV3.0(64) Handshake
2 8 0.2708 (0.0362) S>CV3.0(1) ChangeCipherSpec
2 9 0.2708 (0.0000) S>CV3.0(64) Handshake
2 10 0.3074 (0.0365) C>SV3.0(40) application_data
2 11 7.9036 (7.5961) S>CV3.0(24) application_data
2 12 7.9036 (0.0000) S>CV3.0(104) application_data
2 13 7.9036 (0.0000) S>CV3.0(24) Alert
2 7.9036 (0.0000) S>C TCP FIN
2 14 7.9464 (0.0427) C>SV3.0(24) Alert
2 7.9524 (0.0059) C>S TCP FIN
As you can see session ID is sent correctly.
David

Newly Occuring CSS SSL Issue in Chrome, FF10, IE9 with L5 rules; 3 second delay, loss of L5 stickyness

We recently started suffering an issue with our CSS11501S-K9 units not performing URL stickiness on our SSL wrapped L5 rules. I've spent dozens of manhours working on the problem, and have quite a bit of information to report, including a solution. There is a high probability that anybody who uses SSL to an L5 rule on a CSS unit will become affected by this problem over the next few weeks/months as users update their browsers with new SSL patches.
We hadn't made any changes to our config in months, and eliminated hardware problems by testing a second unit.
Here are the exact symptoms we saw:
Browsers affected: Firefox 10, Chrome, IE9, others (and some earlier versions of IE depending on patch levels)
Browsers not affected: FireFox 3.5, w3m 0.5.2, curl7.19.7
Impact 1: For SSL Rules backed by L5 rules, the initial response to the first request would be 3 seconds. Further requests on the same TCP connection would not be delayed
Impact 2: L5 rules being accessed via SSL would nolonger perform any URL based stickiness. Accessing the same rule skipping SSL, would work fine
I focused on the 3 second delay, since that was a new issue and was easier to debug than monitoring multiple servers to see if stickiness was broken. This is what I found when a client tries to connect to an SSL rule that ultimately is routed to a L5 HTTP rule:
1. Client/CSS perform initial TLS handshake, crypto cyphers determined (nearly instantly)
2. Client sends HTTP 1.1 request for resource (nearly instantly)
3. 3 seconds of no traffic in our out of the CSS related to this request
4. CSS opens an HTTP connection to backend webserver, backend webserver responds (nearly instantly)
5. The CSS seems to route to the backend server using the balance method (round-robin) instead of the advanced-balance method (url)
6. Response is sent to the client with the resource (nearly instantly)
7. Future requests sent from the browser on the same TCP connection have no delay, but the advanced-balance continues to be ignored
The 3 seconds is quite an exact figure (within a few milliseconds) and appears to be entirely happening inside of the CSS unit itself, since it does not connect to the backend server until after the 3 seconds elapse. 3 seconds smelled like some sort of internal timeout set in the CSS unit after it gives up waiting for something.
Looking at the packets from affected browsers I discovered that the GET /foobar HTTP/1.1 request was being broken into two separate TLSv1 application messages, the first was 24 bytes and the second was 400 bytes. Decrypting these messages I found the first message was a
G
and the second message was:
ET /foobar HTTP/1.1
This essentially splits the initial request the client is sending into two pieces. This confuses wireshark so much, it doesn't decode this as a HTTP request, and just decodes it as "continuation or non-HTTP traffic".
On the working browsers I saw only one TLSv1 application message, decrypting it I saw:
GET /foobar HTTP/1.1
(obviously I'm simplifying the contents of the request, there were lots of headers and stuff)
I am aware that the CSS can't handle L5 rules appropriately if they get fragmented, so I suspected this was the problem. I pulled a packet trace from a few years ago, and at that time confirmed we never saw a double TLSv1 application messages before.
A number of openssl vulnerabilities were recently fixed: http://www.ubuntu.com/usn/usn-1357-1
and browsers may have been recently updated to fix some of these issues, changing the way they encode their traffic.
Solution:
Our ssl config looked something like this:
ssl-proxy-list SSL_ACCEL
ssl-server 10 vip address XX.XX.XX.XX
ssl-server 10 rsakey XXXX
ssl-server 10 cipher rsa-with-3des-ede-cbc-sha XX.XX.XX.XX 80
ssl-server 10 cipher rsa-with-rc4-128-sha XX.XX.XX.XX 80
ssl-server 10 cipher rsa-with-rc4-128-md5 XX.XX.XX.XX 80
ssl-server 10 unclean-shutdown
ssl-server 10 rsacert XXXXXX
Removing:
ssl-server 10 cipher rsa-with-3des-ede-cbc-sha XX.XX.XX.XX 80
Solves the problem. After that's removed, the browsers will nolonger fragment the first character of their request into a separate TLSv1 message. The 3 second delay goes away, and L5 stickiness is fixed. The "CBC" in the cyper refers to Cypher-Block-Chaining (a great article here:
http://en.wikipedia.org/wiki/Cipher-block_chaining), and breaking the payload into multiple packages may have been an attempt to initialize the IV for encryption -- although I'm really just guessing, I stopped researching once I verified this solution was acceptable.
This issue became serious enough for us to notice first on Monday Feb 13th 2012. We believe a number of our large customers distributed workstation updates over the weekend. The customers affected were using IE7, although my personal IE7 test workstation did not appear to be affected. It's quite possible our customers were going through an SSL proxy. I suspect as more people upgrade their browsers, this will become a more serious issue for CSS users, and I hope this saves somebody a huge headache and problems with their production environment.
-Joe

Hi Joe,
That's a very good analysis you did.
As you already suspected, the issue comes from the TLS record fragmentation feature that was introduced in the latest browser versions to overcome a SSL vulnerability (http://www.kb.cert.org/vuls/id/864643). Unfortunately, similar issues are happening with multiple products.
For CSS, the bug tracking this issue is CSCtx68270. The development team is actively working on a fix for it, which should be available (in an interim software release, so to get it you wil have to go through TAC) in the next couple of weeks
In the meantime, as workaround, you can configure the CSS to use only RC4 cyphers (which is what you were suggesting also). These are not affected by the vulnerability, so, browsers don't apply the record fragmentation when they are in use. This workaround has been tested by several customers already, and the results seem to be very positive.
Regards
Daniel

CSS bad stickiness

Hi all,
seems we have some problems with stickiness src-ip on a CSS 11506. 6 clients are calling 4 servers.
The four servers are balanced this way:
content Prodotti_9503
add service Prodotti_BEA_WLS_9501_1
add service Prodotti_BEA_WLS_9501_2
protocol tcp
port 9503
vip address 10.216.86.153
advanced-balance sticky-srcip
add service Prodotti_BEA_WLS_9501_206
add service Prodotti_BEA_WLS_9501_207
active
All the traffic goes to Prodotti_BEA_WLS_9501_1 regardless of the client source IP.
All the servers are active.
Do you think this is due to the limited number of clients (the clients are frontend web servers)?
Do you know how the CSS hashing algorithm works in detail?
Thanks in advance.
Fausto

I just upgraded from a set of 11800's to 11506's. I'm running 7.20 build 206. We are doing a data center migration so it was a perfect time to upgrade and break my load-balancing out between internal and external users.
We made the change two nights ago and I spent most of the next day and yesterday troubleshooting some css issues that cropped up. One was with our online bill payment app and the other an agent and reseller site. Both have standard port 80 URL's that then redirect to https for login. Both were configured for sticky-srcip-dstport and immediately began having issues. If you went to servers directly everything worked fine.
Because of the way the redirects are setup we had a hard time getting them working when the sites were first setup. The port 80 rule listens, hits a server then it redirects back to the VIP address and the port 443 rule then reflects it back to the server. After the migration it appeared that intermittenly users would be redirected back to a server that didn't know about their session and browser errors would occur. I was able to set both of those to use ssl session ID and it fixed the issue.
I have another application that seems to be doing something very similar but it has no ssl piece so advanced-balance ssl will do no good with that one. I'm still searching for a workaround.
If anyone here has any suggestions they would be greatly appreciated.

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

CSS SSL Proxy - how can I write the original source address in http header

I'm replacing some BigIP's with CSS11500's that are configured to do front/backend ssl proxying in a one-armed configuration. The BigIP's write the original source IP address as a http header value when the traffic is sent to the application, and the application uses the IP to match against an application ACL. How can I do the same in the CSS.
thanks,
Brian

here is what you can insert with the SSL module :
http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_configuration_guide_chapter09186a0080292a76.html#wp1027619
Gilles.

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.

CSS SSL renewal problem

While renewing the ssl certification in CSS everything went fine while installation but after that when i checked with the following command
sh ssl associate rsakey | grep url(dont want to mention name)
i can see the previous as well as the new both key as associated and says yes
while the new should show yes and old should be no
same it is showing for cert
can anyone help me to sort out with this problem what it can be
Thanks in advance

Sagar,
Have you performed the "no ssl associate rsakey" and the "no ssl associate cert"?
After that, perform the "clear ssl file " and "clear ssl file rsakey "
HTH
Dave

CSS + SSL - unable to create RSA association

Hello,
I am having troubles creating an RSA association on our CSS11506.
Here are the steps I've tried:
1.) I take the original "Digital ID Class 3 - VeriSign Server OnSite" certificate provided to us and move to the CSS via FTP. I have used the openssl verify process to make sure it was a good cert.
CSS-EC1# copy ssl ftp FTPSRV import websrv-gr.pem PEM "thepassword"
Connecting (/)
Completed successfully.
(also at this step - I have tried this with and without a passphrase with the same results)
OpenSSL verify:
C:\OpenSSL\bin>openssl verify -verbose -CAfile .\PEM\verisign.pem websrv-gr.pem
websrv-gr.pem: OK
2.) I then create a certificate association:
CSS-EC1(config)# ssl associate cert WWW websrv-gr.pem
3.) I then attempt to create and RSA association:
CSS-EC1(config)# ssl associate rsakey WWW-RSA websrv-gr.pem
%% File does not contain an RSA key
What can I do to get rid of this error? Does the certificate we recieved from Verisign need to be chained with the Verisign Intermediate certificate?
Any ideas?
Thanks in advance...
Regards,
Ben

Hi
we have a customer with a similar problem,
CSS11501(config)# ssl associate rsakey vimageprivkey privkeyvimages.pem
Error: %% File does not contain an RSA key
The openssl utility has been used to extract the rsakey from the PKCS12 file.
They have used this method numerous times before without this error.
RSA key below:-
Bag Attributes
localKeyID: 31 31 36 33 30 38 34 35 35 32 32 33 30
friendlyName: vimages 2006 certificate
Key Attributes:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,4B31C6E8188C1E2C
L2zTgx4mEUBG0465IxpNOfeyoMX8vTXF6TTrClc5BCDqEYa+K8/9yu6ZwQ+GKdV2
WN0NES4mNMyqB+j2K9ysQi59Zw661MSf/ToTLPgbFlI7xK434ZpMiy6K0VIK8cSW
Nz8yTSbjarpsrigUYzoJ83p10a6vVXA/dEDGrMn84EQeYWjQdStcHU8DKmgaOMLY
c3s68BHex2oNOdG4P4Uo4lTG1zmQOyP0aY7KHv0KNVrR/RNSW4j01nAdPZ09YiiZ
Uu83Kvh/kwkGBhGYAr0vnlqPlsdUarfXams39F/Imp3NQdofXsrVencUjST4zjPK
1xpptY2RYa4lCEZBF5+Y00QhxaQR8IuLkh0x2niR/Nz+KBHxOJ8hacB/bcIpZKv0
ikFDiXoGLgRNCRM1qhECyfUk4Gt95J4qKSAsyUNOTjhaz73q+sUPu6eLffwUQ1U2
g6fNcqAu6z5xJkpPjVtGVt+opERqGrnlCW2R6I1QYio+U21p4Cx+7qfxrGGpZtt+
p0kYhEH9ZMODh8QhDEDv7qqLASQ5aQMcJSLIXCrV13R+yN/qr8qOUDKA88a9avIg
cArcSEWSQ91ZxYYIijnqMHNBWs1REM6U/FRuW28yM4JtZTyxB8baZUVczAfOnOja
yAuJ0UVyshNOZxk5W1OJTjrkqY7+JM0CdnJuYUSqvsQb9L3hiAJ/wHzUQw5pN1J3
Igoo6eLoBj2QC2Fgz1TwJEohelF3F+BVlEvjWjPHi5D0r2e1+HDNNjpWWZctebp7
Aw7kguV1bymfiG3stoHkP/VU2MyCznS6vXI/PWh4KgI=
-----END RSA PRIVATE KEY-----
Any Ideas ??

CSS - SSL Stickiness

Similar Messages

Maybe you are looking for