The choice of CA is not so much related to using a reverse-proxy-style (mitm) service such as Cloudflare.
Of course, it's still important to choose a decent CA due to other reasons (quality of OCSP responders, for instance).
As for previous DDoS, do you remember what sort of DDoS it was? Except for the really overwhelming ones, they can be simple to thwart.
1Gbps (or more) connection helps, enabling TCP syncookies under load will kill all syn floods attacks, and a decently configured firewall that drops unecessary probes and responses to closed ports is also necessary.
You can also rate-limit at the firewall how many new connections over a period of time a single ip can make.
Putting up a high-quality load balancer (even if it's just one backend server (the forum) behind it) such as HAProxy in front of the webserver can also significantly help in a DDoS scenario -- and just in general -- by doing protocol-level checks, adding security rules, and most importantly in this case, gaining the ability to queue incoming connections (rather than just dropping them) so that the backend webserver(s) never have to deal with more that they can eat.
If you want to go REALLY hardcore, then using varnish in front of the webserver and caching the dynamic content on the forum (some VCL mastery needed to make sure the cache is invalidated in a timely/correct manner) such that the webserver doesn't even see most of the requests since they are served static from varnish..
My point is, there is a LOT one can do to mitigate a DDoS attack, and force the attacker to really throw several gbit/s at you rather than relying on simpler to execute ddos techniques (and at that point, if you can detect a pattern in the ddos, getting in touch with the provider and blocking these traffic patterns will help in a pretty good portion of cases!).. the hardware investment, unless you want to start doing DNS round-robin load balancing and having backend webservers in multiple datacenters with a replicated database also in multiple locations, is negligible.
So, a good relationship with the upstream provider helps. Many times in the past, for me, it was a matter of calling the datacenter, giving them a list of IP ranges, or a range of UDP ports, or whatever pattern could be detected in the DDoS, and ask them to temporarily block traffic upstream. Most of the time that immediately brought the customers' site back online.
edit: Aware of letsencrypt, but haven't played with it yet. Good initiative. Cursory rtfm seems to indicate the official client requires root to run, which I would say is an unacceptable thing on a producting server (for the purpose of generating/updating ssl certs). There seems to be a -nosudo variant around on github, anyway, I would recommend not running it as root in the production machine.