Best practices for implementing redundancy and availability for Quest SSL-IT

Hello experts,

below you will find the exact question I have just submitted to the Quest Support Team regarding to Best practices for implementing redundancy and availability for Quest SSL-IT. They've just informed me that they've submitted my question off to the vWorkspace Product Team to see if any of the consultants can provide support.

It would be very interesting to know some opinions from you guys on the field:

we currently have the following vWorkspace production environment:

- 1x dedicated Windows Server 2008 x64 Virtual Machine positioned in the DMZ with Quest SSL Gateway service installed and running
- 1x dedicated Windows Server 2003 Virtual Machine positioned in the DMZ with Quest Web-IT service installed and running
- 1x dedicated Connection Broker Virtual Machine running Windows Server 2003 installed on a separate machine located on the production LAN along with the Terminal Servers

Remote users only use vWorkspace Web Access client to retrieve their list of allowed published applications using their web browser.

We are about to renew our thawte SSL certificate installed on Secure-IT server since the SSL certificate currently installed on Secure-IT server is about to expire.

The reason why we are contacting you is that we have also been asked to provide redundancy and availability for vWorkspace Web Access published applications.

More specifically to access vWorkspace Web Access published applications remote users are currently connecting to the Secure-IT server to https://secure.domain.it which represents the only domain name included in our thawte SSL certificate and maps to a Public Static Ip address from our primary ISP link. Should the primary ISP link fail, the corporate firewall will automatic fail over to a backup ISP link which however uses different Public Static Ip address. Our first thoughts about how to face such situation is to renew our thawte SSL certificate while including an additional domain name (e.g., backup.domain.it) in the new SSL certificate. The backup domain name will obviously map to a Public Static Ip address from the backup ISP link pool.
Remote users then will be instructed to manually connect to the backup Secure-IT server domain name (e.g., https://secure.domain.it) if the primary domain name (https://secure.domain.it) becomes unavailable because the primary ISP link fails.

Questions:

- would you recommend us to include both the primary domain name and the backup domain name in a new single SSL certificate which then will be installed on the Secure-IT server so that the Secure-IT server will act as the single access point to the vWorkspace-enabled infrastructure from both ISP links (the VMware vSphere 4 virtual infrastructure where the vWorkspace Virtual Servers resides will ensure redundancy and availability for the virtual machines themselves)
- would you rather recommend us to only include the primary domain name and backup domain name in different SSL certificates which then will be installed on different Secure-IT servers so that each server will act as the single access point to the vWorkspace-enabled infrastructure from a specific ISP link ?
- would you rather use different methods to accomplish this job ?

If you need any further clarifications, please do not hesitate to contact me.

Thank you and have a great day.

Best Regards,

Massimiliano