1 Reply Latest reply: Oct 24, 2017 3:27 AM by rgirdlestone . RSS

SLL Optimization & Secure Peering


Hello everyone,


Currently all secure traffic is being bypassed on the SH and I need to start optmizing this traffic.


Reading the DG I need to clear some things up:


By the way, I'm running 8.6, client and Server.


The steelheads are not reachable over the internet so I'm assuming I don't need a proxy certificate, the proxy certficate would be suitable if I had like an exchange server behind the SH, right?


Basically I want to optimize the SSL traffic from a branch office to the main office where internet breakout is at.

If I understood correctly to have this communication secured all I need to do is add the certificate from client SH in the server SH and the server certificate in the client SH.


Also, can this be self signed?


Thanks in advance.

  • Re: SLL Optimization & Secure Peering
    rgirdlestone .



    there are many things you will need to do to optimize your SSL backhauled to the DC.  Only one of which is the secure peering trust relationship between the SHs.  You are correct that you have to swap the certificates, but there are many ways to do this.

    1) Use a policy push from the SCC on the peering-trust page (really easy)

    2) Use the gray and white lists on the secure-peering pages of all the steelheads (labour intensive and a but amateurish)

    3) Use the CA function of the SCC (really great, but read this first: How To Guide for SSL-CA Signing Services.pdf

    4) Manually export the certificates from each SH and create a large txt file with all of them pasted as txt in it.  Add that file as a trusted entity on each SH.  (Long job and a boring one).


    My favorite is the CA function, a little effort now will save a great deal of work in the future.


    BUT:  It does not end there.  You will have to do the in-path rules for the client side SHs, so as to pre-empt the pass-thru rule for 443.


    You will also have to add a proxy certificate for the internal servers that you wish to optimize AND ensure that all the user devices trust that certificate.  Usually this is done as a policy on the Domain Controllers.


    Keep in mind that one of the internal servers might be a proxy server.  If so you will have to be able to differentiate HTTPS and HTTP running over the proxy port.  Perhaps 8443 and 8080 respectively.


    The deployment guide is a great source of info, as is the WAN310 class if you can get on it.






    PS make sure you have the crypto license (FoC from the support website)