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)