Could you specify your question more specific? Because there currently are three (3) ways for Let’s Encrypt (LE) to validat a domain for issuing certificates, of which 1 is dependend and 2 are independend of the fact if a host is a virtual one or not:
dns-01 challenge: you put a specific TXT record (containing the ‘token’ for authorization) ‘below’ the domain you’d like to validate and LE checks this DNS-record. It proves you’ve got control over the FQDN. This challenge would be independend of the way a webserver provides its hosts, virtual or not;
tls-sni-01 challenge: the client generates a custom, not-for-general-use certificate with the ‘token’ as the domain name for that certificate and your webserver will provide this certificate when specifically asked by the LE server through SNI. This challenge would also be independend of virtual hosting or not;
http-01 challenge: you put a specific file containing the token in the /.well-known/acme-challenge/ dir under the (virtual) host (corresponding with the FQDN of which you would like a certificate) of your webserver and LE checks the existence and contents of this file. This would of course be dependend of the (virtual) host, but it should not matter if the host is “virtual” or not. Just as long as anybody can reach it publically…
I think I just found the answer I need. It looks like the dns method is
best for me to get a single cert for each of my several domains and
subdomains which move around on several servers occasionally. I’m going to
try the acme.sh client to do that.
@schoen, I’ve changd my mind: I’m going to try the full auto route (Apache 2.4, Debian jessie, 64-bit). I currently use one cert per vhost and would like to continue that. From my looking at the docs it looks like I would need a separate run of certbot for each domain. Questions:
Typically it will be whichever one you specified first on the command line with -d, e.g. /etc/letsencrypt/live/example.com if you ran with certbot -d example.com -d www.example.com.
In the sense of being the only one in possession of your private key? Yes, it’s generated on your own machine by Certbot and never shared.
In the sense of being able to choose a private key of your choice? Currently this doesn’t work in Certbot with automatic renewal. There is a way to specify a CSR on the command line if you generate it externally, which allows you to use a private key of your choice, but then Certbot will not be able to renew the certificate for you.
Yes, currently that’s a requirement (unless you use the CSR approach I mentioned above). They will also currently change with each renewal. We have an issue and some work toward a new feature where you can keep the same key pair when renewing.