测试环境
1.配置一个自签发证书
2。配置一个自定义的clientssl profile，在该自定义profile中调用上面签发的证书
3.VS中调用该自定义clientssl的profile
测试结果：
如果访问的服务器页面进行了重定向的话 则会出现问题。如果不重定向则正常，例如：
本来http://10.7.7.20访问真实服务器则自动重定向到http://10.7.7.20/site地址，配置了F5上的SSL后，https://10.7.7.20则不正常，无法打开。
----补充,个人经过抓包分析,不知道对否
当在浏览器敲入HTTPS地址之后，客户端与服务器端进行了如下工作：
1。建立TCP三次握手
2.进行4步的SSL协商过程（client hello, server hello-certificate-server hello done , client key exchange , 服务器端change cipher spec）
3.关闭TCP
4.再次进行3步SSL过程(client hello , server hello , 客户端change cipher spec)
5.开始交换数据
而对于实际服务器会进行URI跳转的情况，我抓包发现如下：
1.建立TCP三次握手
2.进行3步SSL过程(client hello , server hello , 客户端change cipher spec)
与正常情况下没有了那SSL的4步骤。不知道是不是由于服务器发出了302状态的跳转指令而导致SS协商失败。
附截图：
正常过程截图
非正常过程（实际服务器会跳转）
------------------------------感谢信诺瑞德朋友-----------------下面是查资料后的分析-------------------
VS :https://192.168.162.250 实际服务器服务10.7.20.240:80且服务器会重定向http://10.7.20.240.80//bg/main/login.jsp
由于用F5执行SSL后，用户访问的请求是https://192.168.162.250 ，而实际服务器返回的302状态LOCATION的值却是http://10.7.20.240.80/bg/main/login.jsp，这样http 响应在经过F5后，LOCATION自动被写为http://192.168.162.250/bg/main/login.jsp，而192.168.162.250:80这个VS是不存在的，所以访问过程中断（经实际测试，我故意新赠一个VS 192.168.162.250:80，证实了这样的自动跳转）。为了解决https与http这样的重写问题，F5提供了redirect rewrite的功能，F5可以根据要求进行LOCATION内容的重写，用户访问的请求是https://192.168.162.250 ，只要保证用户最终看到的LOCATION是用户访问的请求是https://192.168.162.250/bg/main/login.jsp就可以了，在http profile中选择redirect rewrite 为ALL 。
当设redirect rewrite设置为ALL 时候，F5对LOCATION内容进行基于VS的协议、端口的重写，并自动根据情况将HOST重写。
如果VS还是HTTP，那么重写该如何，还是上面的服务器，VS这次改为80，下面是分析过程。
1.如果redirect rewrite不设置，正常
2.如果redirect rewrite设置为ALL ，不正常
3.如果redirect rewrite设置为matching ，正常
分析1.不设置重写的时候，F5默认也是自动将LOCATION中的HOST地址替换成VS的。
分析2.当设置为ALL的时候，抓包发现LOCATION被写成了https://192.168.162.250/bg/main/login.jsp 再次说明ALL是对协议 端口的整个重写。
分析3.设置为matching，F5可以根据LOCATION与原始请求比对，决定是重写还是不重写，实际测试发现，如果原始请求地址与LOCATION不同，则会重写，而如果实际请求地址就是LOCATION地址的话则客户端接不到302(如果是HTTPS与HTTP转换的话，设置为matching的时候则原始请求必须等于LOCATION，才能让客户端接不到302，而如果不相同，则F5会转换HOST部分，但协议和端口还是不转的，因此如果要转换协议或端口，一定要选ALL)。
设置为node模式，则可以让F5将原始LOCATION中的实际服务器地址替换为VS地址，以便实现均衡。
文章评论
配置 http profile redirect All