Crap. I had certs set to expire on 2/28! I was going G to be saved by wildcard. Off to make a bunch of DNS entries....
Certbot's own autorenewals (which I originally implemented and which I hope are currently working for you -- I'm happy to try to find a way to get them to work in your deployment if they're not!) try by default to renew certificates 30 days before expiry in order to give people a lot of time to notice and intervene if something goes wrong. Consistent with that, I'd encourage all of our users not to rely on anything happening less than 30 days before expiry as part of their plan for keeping certificates current on their sites.
One thing to know about the TLS-SNI situation is that TLS-SNI-01 has been disabled for new issuance and only works for renewals. The selection of authentication methods is pretty transparent because the ACME protocol allows the CA to state which methods it will accept for a particular domain authorization (so for the renewals it can state that TLS-SNI-01 is permitted, while for new issuance it can state that it's not, and a client can respond accordingly).
Apparently the ACME WG is working on a TLS-SNI-03 method that will be safer and that might be supported by Let's Encrypt (and ACME clients) at some point. But it's also possible that TLS-SNI-01 could be disabled in the future, even for renewals, even before TLS-SNI-03. So, if you happen to have anything in your setup that prevents the use of HTTP-01 on port 80 for authentication, you should be aware that renewals could potentially stop working at some point (although this isn't imminent), and that you might also have difficulty adding new domain names to your certificates.
https://community.letsencrypt.org/t/important-what-you-need-...
This unfortunate situation is a nice showcase of the ACME protocol's flexibility, because the CA has a way to tell the client very specifically what authentication methods to attempt or not to attempt for each domain (and if new methods are specified in the future, they can be rolled out incrementally without breaking compatibility).
Right now a researcher with 5 million Let's Encrypt certificates can see which ones use public keys with unusual patterns, how many are for names in the French .fr TLD, how many have longer key lengths, and so on, but they can't see whether the validation was done with Method 10 (which had this unexpected flaw) or some other method.
Another CA (can't remember which one) was looking at doing this, and it seems like it'd be nice for Let's Encrypt too.
Another concern might be that users might not want this to be disclosed because it might give attackers suggestions about how to attack their renewal processes (although of course CAs have been willing to publish information, like issued certs, that some users wouldn't prefer to make public).
The main challenge is that wildcards require DNS authorization, so a full automation is DNS api specific. My DNS (OVH) has a neat rest API. But given the variety of DNS providers and APIs it is going to be challenging to rely only on a reference implementation without wrtiting a little bit of code yourself.