Let's Encrypt and Reverse Proxy: Does the Proxy need a cert as well?

1. The certificate (and key) are what "owns" the domain. That is why it is super important that you do not allow the key to fall into the hands of anyone else (you need both the cert and the key).
   
   So even if your server has a valid certificate, if you browse to it via a different domain (if you have DNS configured to point an additional domain to the same server; e.g. a reverse proxy); or even an IP address using HTTPS, you will get a warning (the certificate that it provides, doesn't match the address you're using).
   
   So yes, simply copying it across is fine (FWIW, by default, we bundle the cert and key into the same file, but they are also available separately). So long as you have the configuration correct, then it should "just work".


2. I don't have any sample config, but it's super simple. Just have the backend server redirect to plain HTTP and use "http://" stanzas within the reverse proxy... Again, it should "just work".
   
   The reference to URL spoofing is because when using vanilla HTTP (i.e. not HTTPS) there is absolutely no guarantee that the server is what it says it is (HTTPS provides that guarantee). A malicious actor can easily do a "man in the middle" attack (i.e. pretend to be the server you want to connect to and harvest the traffic).


3. If you want to host multiple sites on a single server, then what you want to read about is "named based hosting".
   
   It's worth noting, that that's essentially what a reverse proxy does. The difference is that the reverse proxy hands the traffic off to another server. Also FYI, whilst lots of people rave about Nginix, IMO Apache is the easiest webserver to work with for this stuff (especially if you have no shortage of resources - it tends to be a bit "heavier" than Nginx)).
   
   Here's the relevant Apache doc page and here are some examples (again from the Apache docs).

Regardless, I get you with your comment on having a reverse proxy and multiple separate servers. The reverse proxy is still a single point of failure, but the added redundancy of separate servers is good IMO.

FYI I use Proxmox VE as my server "lab" host. It's also Debian based and has a pretty web UI, plus a powerful CLI. It includes other features too that I don't use (such as clustering) but it works awesome for my needs.

One of the beauties of it IMO, is that it supports/provides KVM (for "proper" VMs - including alternate OS, such as Windows) and LXC (container based hosting; which has extremely low overhead). LXC is awesome IMO, you get most of the advantages of a VM, with virtually no overhead (i.e. LXC containers run at near native hardware performance). TurnKey containers are actually available to download from within the PVE UI too! :) Or you can install from ISO if you want a "proper" VM. For my TurnKey development, I run multiple instances of TKLDev on KVM (i.e. installed from ISO).

Thanks, Jeremy.  Similar to another question you answered for me today, your answer is once again clear.

Some follow up questions, if I may:

1. My reading of some documents on the Internet seems to suggest that a cert is tied to the server and domain name. I got this impression from this statement from DynU.com in answering a FAQ question from their customers:  "I host my website on a dynamic IP, can I use an SSL certificate?  Yes! SSL certificate is associated with the server and the domain name, but not the IP address. If the IP address for your website changes you don't need a new SSL certificate." 

So if this is the case, can I really, as you suggest, simply copy the cert from the Reverse Proxy to the WP Appliance that's serving up the Wordpress page?  

I'm concerned because WP Appliance would be a different "server".  [Technically all the servers are just VMs...]  Wouldn't the cert, being now on a different server be no longer valid?  [Note, I'd be very happy if simply copying the cert over is good enough.  I wasn't looking forward to creating a cert  on every Wordpress server I setup...] 

2. I like your suggestion of doing "User <--HTTPS--> Reverse Proxy <--HTTP--> Backend Server".  Do you have some sample configurations (or pointers to where I can look) for a reverse proxy that can do that?  That sounds a lot easier and less messy than 

User <--HTTP--> Reverse Proxy <--HTTP--> Backend Server
User <--HTTPS--> Reverse Proxy <--HTTPS--> Backend Server

In some ways, I am not too worried about security.  Though I'll want to research "URL spoofing non-HTTPS servers"...  

There is no serious data at all on any of these servers.  And my server "farm" is on its own network, separate from my home network.  So no breaches or compromises would reach over.    

I just want the websites to look professional (have the HTTPS lock symbol) and protect my credentials when I log into my Wordpress servers to add content.  

3.  Number 3 is not a question, it's just a comment/reply to your suggestion about having the Reverse Proxy be the Wordpress server for one of the domains and then reverse proxy traffic for other domains of mine to other servers.  

You have a point.  And I believe I could even do away with the Reverse Proxy altogether if I could figure out how to host more than one domain on my TLK Appliance (which I understand is a common thing to do; I've seen some hints or sample configs on how to do it.).  

But I LIKE the idea of having a reverse proxy and multiple separate Wordpress servers.  While all these servers are in reality only VMs, I can still fantasize about having a giant rack of physical servers, each having a single purpose:  FILE-SERVER1, PROXY, WP1, WP2, WP3, VPN-SERVER, EMAIL-SERVER, DB-SERVER, etc!  That is, I can dream of running my own data centre!  Ha-ha!  

The Reverse proxy will need to hold all the SSL certs of the sites (i.e. domains/sub-domains) that it is serving. That is because when a user connects via HTTPS, their connection is with the reverse proxy. The connection to the backend server is between the reverse proxy and that particular server. So whilst the reverse proxy generally doesn't do anything with the network traffic, it essentially relays it between the backend server and the client.

It's perhaps worth noting, that depending on your use case, one of your servers could be configured to act as a reverse proxy as well as serving content (rather than having a separate "stand alone" reverse proxy server). E.g. your WordPress server could serve all content for wp.my-domain.com and reverse proxy traffic to oc.my-domain.com (and others). You would then configure your WordPress server to get certificates for both wp.my-domain.com and oc.my-domain.com (and as many as you want). Note that whilst the TurnKey UI only has support for 4 domains/sub-domains, you can configure it manually to validate as many as you want.

On the backend, for simplicity you could just proxy plain HTTP traffic. I.e.:

User <--HTTPS--> Reverse Proxy <--HTTP--> Backend Server

In other words, not worry about HTTPS within your network. This does have some potential security implications, although I would argue that on a home style network, if you have untrusted clients on your LAN, then you have bigger problems than URL spoofing non-HTTPS servers...

Alternatively, you could just copy the relevant cert to the backend ownCloud (&/or other) server(s). This could be easily automated, perhaps as part of the certificate renewal or as a separate cron job.