@Twansparant I don’t think you need to delete CSRs or certs. The other thread’s suggestion to do so was to deal with a problem fixed in Jan 2017. It appears your version of Trellis has the related fix, given your filename example.dev-86aea94-bundled.cert (cf. this addition). In any case, you should be able to work with those files as the admin user by invoking sudo, e.g., sudo ls -alh /etc/nginx/ssl/letsencrypt using the admin_user's password.
I don’t remember any reports of the Test Acme Challenges task ever taking longer than 5-15 seconds. That task corresponds to a step Trellis takes before asking the LE server to verify your domain (see SSL docs on Challenges) :
5. LE client creates a "challenge" file in the web root of your site
here --> (Test Acme Challenges)
6. LE server verifies it can access the challenge file
If that task is failing, it suggests that the Acme challenge file is not publicly accessible at one or more of your site_hosts. You can test the accessibility manually:
# should give a `200` response code
$ curl http://example.com/.well-known/acme-challenge/ping.txt -w "%{http_code}"
200%
Try the command above for each canonical domain and each of your redirects, for sites with ssl.enabled: true. If any fails to give 200, the challenge file is inaccessible. In that case, let’s check whether the domain is accessible
# if ssl enabled, http may give a `302` response (redirecting to https)
curl -kI http://example.com
If the above doesn’t show a successful connection (200 or 302 are examples of successful), ensure that you have DNS setup for the failing domains. I’d be surprised if for any domain the challenge ping.txt was inaccessible but the bare domain is accessible.
In some rare cases (example), firewall/networking setup can interfere with Let’s Encrypt challenges.
If problems persist, you may want to post your wordpress_sites for review.