It is true that you can forward connection-establishing packets from clients in the internet, which come the static public IP of the CHR, a) to the current public IP of the router in front of your web server (so outside the tunnel) or b) to the server’s private address (so inside the tunnel). But you also have to ensure that the responses to the clients will arrive from the public IP of the CHR, and this is impossible to achieve in case a).
The point is that the TCP session is identified by the quadruple of (client-side IP, client-side port, server-side IP, server-side port) and if the client receives the response from a different IP:port than to which it has sent the request, it will not recognize it as a response to the request and will drop it, and so will do any firewalls between the client and the internet. And in case a), the request from client will be redirected to the current public IP of the router in front of the server, but you cannot route the response through the CHR outside the tunnel without losing the actual address of the client (which is the destination address in the response packet, so once you rewrite it by CHR’s address to force the packet through the CHR, the CHR has no way to restore it). And as more data is likely to flow from the server to the client, there is no point in routing the client requests outside the tunnel.
So it only makes sense to deal with case b). Your existing routing on the CHR knows the route to server’s private address via the tunnel, so a dst-nat rule from CHR’s public IP to the server’s private one (and the firewall filter allowing the dst-nated packet to be forwarded) are all you need on the CHR.
On the server’s router, however, you need to make sure that responses to connection requests coming via the VPN tunnel will be routed through the tunnel although the default route is through the regular WAN. This can only be achieved using connection-based policy routing which is explained in this post; start reading it from the last paragraph which will explain the link to your case. If it is not clear from there, komm zurück 
If you can afford to dedicate a local interface and a dedicated VPN tunnel for the access to the server from the internet, you can also replace the above approach by a VRF setup, where the dedicated VPN tunnel and the local interface dedicated for the server would share a common routing instance (a vrf-assigned routing-mark). In fact this approach may turn out equally complex as the above as soon as you start thinking about management access to the server, but the advantage of this approach is that you can use fasttracking on the server’s router, so if it’s throughput becomes the bottleneck, take this way.
EDIT: of course you can also simply src-nat the packets from the clients to the server at the CHR to force the responses back through the CHR, but this would mean that the server would see all client’s connections as coming from the CHR itself which most people want to avoid, so I neglected this approach.
