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"?
Note: all my subdomains seem to work as expected eg. www.example.com, blog.example.com, etc. when they are entered directly into a browser.
Steve
PS: I've run out of update attempts so will need to wait a week to try again 
Welcome Back to the Let's Encrypt Community, Steve 
A certificate for only *.example.com won't work for example.com. You need a certificate covering both.
I would certainly hope so if you installed a wildcard certificate.
Not necessarily. 
What is the actual domain name?
The actual domain name is "stevewright.nz"
Steve
I'm guessing you hit the Duplicate Certificates rate limit by repeatedly requesting a certificate for *.stevenwright.nz.
In that case, if you ask for a new certificate for stevenwright.nz, *.stevenwright.nz, that won't be considered a duplicate and this rate limit won't block that request.
OK, this gives me the following error
sudo certbot certonly --apache --expand --preferred-challenges=dns --email stevewrightnz@hotmail.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.stevewright.nz -d stevewright.nz
"None of the preferred challenges are supported by the selected plugin"
which is odd because all I've done is add the --expand option to the command I originally created the cert wildcard with?
and if I use the --preferred-challenges=http option I get a challenge failed error for stevewright.nz
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?).
yeah probably, ill try with that
Yes!!! All sorted - thanks for all the assistance.
Steve
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.
In addition to what @tialaramex said, a.*.c.d is not allowed. The wildcard (*) must be the leftmost label.