The use of “certificates” has been long accepted as best practice for web servers. In the past, deployment of cryptographically secure web traffic has been a fairly expensive undertaking because of the need to purchase such a certificate (which is really a set of encryption keys) from a “certificate authority”.
In about January of 2016, a new certificate authority named “LetsEncrypt” came on the scene. The certificates which they issued were both “free” and “trusted” by most browsers. The LetsEncrypt effort has greatly encouraged the adoption of “secure” web protocols. At this writing (October of 2018) there are more than 70 million valid LetsEncrypt certificates.
The LetsEncrypt certificates have a rather short lifetime and must be periodically reissued or “renewed”. That process is not especially cumbersome, and is automated easily.
Although the original certificates were issued only for fully qualified domain names, one could to some extent handle a few subdomains by including multiple names in a single certificate.
Recently, LetsEncrypt began issuing “wildcard” certificates, which are valid for a given domain, and any subdomains. These certificates have 90 day lifetimes, and must be renewed periodically.
The current renewal protocol involves issuing a “challenge” request to domain name service, asking the authoritative DNS server to present a specific TXT record as part of a “handshake” to authenticate the exchange and allow the certificate authority to establish the identity of the server making the request for renewal.
There is a shell script, termed “acme.sh”, which can interact with the LetsEncrypt issuing authority, accept the challenge, and issue, via an API, orders to the DNS server to present the specific TXT record to meet the request, thus “validating” the request and allowing the renewal to proceed without human intervention (ie via cron, or other scheduled means). In other words, it can automate the renewal process.