You've got a few options here:
- Go down the route you mentioned, terminate your SSL at a cluster of HAProxy instances before forwarding the traffic through your ELB to your instances.
- Turn your ELB into a TCP-forwarder, which makes ELB a dumb packet shuffler. You lose some benefits of ELB here, but this will work. You'll terminate SSL at the instances that are hosting your application in this scenario, so in a load balancing configuration, you'll need copies of the certificate on all your instances. Could be quite tricky to orchestrate, but feasible.
- (and my preferred option) use an ALB. ALB's support multiple SSL certificates and will automatically choose the correct certificate when the client indicates the SNI header. You'll be able to upload the required certificate pieces (key, cert, intermediary) to IAM and select them within your ALB, all via the API.
ALB's have many other advantages than just SNI.. they support HTTP/2, path-based routing to multiple target groups (useful in some scenarios), and as far as I'm aware they're cheaper than classic ELB's.
And yes, Elastic Beanstalk DOES support ALB's. Unfortunately, you can a) only select to use it at environment creation time, and b) only do this via the new UI. I've posted some gripes about UI and EB in general having really gotten into using it over the last few weeks. Hopefully they'll fix these issues in the future. In the meantime, you should at least be able to save your current environment's configuration, launch a new one from the saved configuration (changing the load balancer type before creation), and then switch the CNAMEs once it's up and running.
Note also: your environment must be configured to use a VPC in order to use ALB's.