Sorry this didn't get an answer sooner. Not sure how that happened.
The current f5.http iApp does not expose a way to configure a chain cert when configuring SSL termination. The steps you took are one way (probably the easiest) to solve the problem. The other would be to "fork" the template by making a copy of it and changing its code to allow for this configuration.
An upcoming version of this same iApp will have an enhancement to allow you to specify a clientssl profile created and managed outside of the iApp as a way to allow for using parameters not exposed by the iApp (such as a chain certificate) in the event that the iApp doesn't suffice. It'll actually offer similar options for all of the profiles that a user might want to use with it. This is a compromise between making a concise and focused template and allowing for the use of some of the more rarely used configuration options. However, it's going to be some time until that template is available.
I was able to modify the f5.http template in two places to get the functionality that you're after, but the two changes were somewhat ugly. First, I introduced a new "section" in the presentation with a single question in it that had a small bit of TCL to build a list of ssl certificates. That isn't very clean because it's not part of the SSL section with the rest of the related config - but that section is defined in a library of code used by many templates, and so changing it would impact much more than this one template. Secondly, I had to modify the implementation to modify the client-ssl profile after it was created (again, by a chunk of common code which should be left alone). I would normally just post that iApp, but it's ugly and would make your deployment unsupportable by F5 support should you need to call in about it - and it's just not the right way to fix your problem.
Sorry I couldn't help you more - we're working on a fix for this issue already, but it's just not quite ready yet and the only quick/easy fixes I can offer aren't really appropriate for running in production. What you did for now is probably the best solution at this time.