Based on what you are saying here:
"Specifically, the server must present its server certificate before the client can communicate what host it is connecting to via SNI."
I don't believe that is true.
From: RFC 6066
3. Server Name Indication
TLS does not provide a mechanism for a client to tell a server the
name of the server it is contacting. It may be desirable for clients
to provide this information to facilitate secure connections to
servers that host multiple 'virtual' servers at a single underlying
In order to provide any of the server names, clients MAY include an
extension of type "server_name" in the (extended) client hello.
When the client supports SNI it will send the server name (in the extended field) in the client hello for the server (in our scenario the Check Point) to determine which certificate to send back.
The whole process of selecting which certificate to present / send is based on the SNI extension of the TLS protocol.
The reason that we use SNI is because with the use of TLS there is no way for the server to determine the HTTP host header because it is encapsulated in a TLS header.
So, without the use (support) of SNI the server cannot determine which certificate to send back to the client and if configured, it just throws "a" certificate which without the use of SAN would result in a "Untrusted Certificate" warning in your browser.