OK, this might be just a simple setup issue but I can't seem to make "example.com" work with a wild card certificate in the form "*.example.com". Do I need to expand the certificate to include "example.com"?
By Let's Encrypt policy, wildcard certificates require the DNS-01 challenge (not HTTP-01), which is not supported by Certbot's --apache. But since you got wildcard certificates successfully before, you must have used --manual instead of --apache when you were requesting those (right?).
Since you used --manual, you'll need to run that same command again (interactively) in order to renew this certificate in the future. (Specifically, certbot renew and the Certbot renewal cron job won't be able to do it, because it requires human interaction.)
For anybody who reads this and didn't already understand about wildcards. A wildcard *.example.com matches exactly one label where the asterisk is. A label is the bit between the dots in a DNS name, any other symbols don't matter, only dots separate labels, so "community" is one label, and "free-cheese-and-wine" is one label. You must have exactly one label there for it to match the asterisk, or to put it another way, if some services have a name with fewer (like example.com) or more (like www.test.mail.example.com) labels you want to get certificates that match those names.
Multiple wildcards are prohibited, so while *.*.mydomain.example might seem convenient, even if it was a good idea you can't get that.
A thought for Certbot: In any interactive modes maybe have Certbot explicitly warn that *.example.com does not match exactly example.com if the user seems to have asked only for a wildcard. Some users will really want just the wildcard, but they'd presumably see the warning and think "That's fine, this is what I wanted". In an interactive mode the chances are a human is looking at the output, so hence that restriction.