Ssl – handshake_failure from cloudflare ssl

This is normal - they should have warned you though - and you should expect interruptions for at least the next day (if you're lucky; and the next month if you're unlucky).

Older versions of SSL require their own IP. SNI is a "modern" technology that lets multiple sites share an IP, in the same way that standard HTTP can share via Virtual Hosts. SNI has about 80% support however, and 20% is enough to guarantee that no major hosting site will support it. So when you implement SSL, you require your own IP address (you're probably paying more for this too).

Since you're switching IP addresses, it will take time for anyone who has the old IP cached to grab the new IP. Your TTL is 4 hours, so anyone who hasn't visited your site in the last 4 hours should be working now. Some DNS servers don't play by the rules (and it's too hard to identify them to do anything about it - as much as I'd really like to) and will cache your entry as long as they'd like (which could mean malfunctioning patrons for some time to come).

This is all very common among the hosting industry, though my host gave a huge red warning about interruptions and stuff (they went out of their way to explain the issues, very likely they got tired of having to explain it to people who didn't know already). I'd like to be surprised that your hosting provider didn't, but in honest they're probably charging <$5 a month for basic hosting packages (SSL, Domain name, IP, etc all extra) and are betting they wont piss you off enough to make you leave.

there has to be some way to prevent the server from responding to SSL requests that do not have a valid SSL associated with them

Well, kinda. Since you have multiple sites running on the same IP, a user attempting an SSL connection to that IP for any of the sites will always establish its SSL connection (and potentially get a certificate error if they're pointing to a hostname that isn't covered by the cert).

All you can do to prevent this is to not have SSL listening on that IP (running your SSL stuff on different addresses).

If you're ok with them getting an SSL connection with that potential error, then you have options after; instead of getting the content from the SSL-enabled server, you could have a default of them either getting a 403 error or a redirect to the http listener for the hostname they sent the request to - would one of those options make sense for your system?