WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network. Check out this quarters report on the threats that shook the industry in Q4 2017.
If you are acting as a classic proxy, then you will be forwarding (unchanged) the ssl handshake you get from upstream, and it doesn't matter too much how many proxies that goes though.
If you are intercept-proxying a ssl connection then you have to be able to represent to the end user (either by having a locally installed cert for reverse proxies such as ISA server and iChain, or spoofing the certificate "on the fly" like, for example, ironport WSAs) a certificate they will accept as valid for the url they entered.
If there is another proxy upstream of type classic, then it doesn't matter - you are planning to either pass though or spoof the certificate anyhow.
If there is another proxy of the intercept type upstream, then it gets a bit more interesting. The certificate must be acceptable where used, either at the end client (for a pass though proxy) or on the intercept proxy itself (if the chain has TWO intercept proxies in it, the first must accept the second's certificate)
this is usually the case (In fact, most intercept proxies don't actually care if their upstream validates or not) but there is an edge case where the first proxy's cert would be acceptable to the end user (via group policy or whatever) but is *not* acceptable to the second proxy, and hence that proxy generates an error to the user rather than passing though the traffic.