While I'm not reverse-proxying, I fetch certs on one machine then I have a shell script that passes them around to all the Apache servers.

There are a number of cert types and formats; you already figured out some require concatenation of two or more files together.

It looks like

EC, I would imagine, stands for Elliptical Curve key, where as the other, by lack of designation, I presume is an RSA type key.

I just had a workmate preach the wonders of Caddy to me yesterday (literally- kinda startling to see this thread after) so I'm not educated at all on it. But is there an ability to key key types? Conversely, I'm poorly educated on Apache but perhaps it can be set to use an EC key?

The DH stuff is Diffie-Hellman key exchange data. That lets two devices compute a shared secret for key exchanges. Again, I hadn't heard of Caddy until yesterday but I take it looking around revealed no DH data generated? Perhaps this is some configuration difference in how Apache or Caddy intend SSL/HTTPS to occur?

Hopefully someone with more experience hops in and lays it out.

Firstly, thanks for jumping in and trying to help out Timmy! :)

Assuming that your Caddy instance handles the public TLS termination (i.e. it serves the "proper" TLS certs, from Let's Encrypt), the only thing we need to worry about is the connection between Caddy and the Concrete CMS backend. Here are the configuration options as I see them:

1. www  Caddy  vanilla http (port 80)  Concrete

2. www  Caddy  self signed https (port 443)  Concrete

3. www  Caddy  "proper" (e.g. LE) https (port 443)  Concrete (2 variations)

4. www  Caddy  Caddy CA signed https (port 443)  Concrete

1. vanilla http (port 80)

The first is the simplest and as I understand it, what you were asking for initially. Essentially you just need to disable (i.e. remove from the Apache conf) the https redirect for the log in page. I.e. remove these lines from the Concrete Apache conf (/etc/apache2/sites-available/concrete.conf):

    RewriteEngine on
    RewriteRule ^(.*)/login$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Then restart Apache. Assuming the default file, here's a oneliner to do that (please note that this will remove all lines that include 'Rewrite'!):

sed -i "\|Rewrite|d" /etc/apache2/sites-available/concrete.conf && systemctl restart apache2

Then configure your reverse proxy (something) like this:

concrete.domain.example {
        reverse_proxy 192.168.0.xxx:80
        encode gzip zstd
}

Where 192.168.0.xxx is the private IP of your Concrete instance. Given your example config, I assume that without a port, it will default to port 80 (vanilla http), but personally I think it's best to be explicit.

As I noted previously, historically, this is how it was often done. However, the downside is that the traffic within the LAN is unencrypted, so snooping on passwords, etc is pretty easy because they're transmitted in plain text within the LAN. There is also no guarantee that the backend server actually is the Concrete instance, so MITM attacks are also trivial.

As any attack would require a malicious actor within your LAN, you may be comfortable with that? Obviously, the value/importance of the content is also a factor.

2. self signed https (port 443)

The next option is to just use the default self-signed TLS cert (or regenerate it) on Concrete (i.e. the one that TurnKey servers generate on first boot). TBH, I'm not actually 100% sure whether this is possible with Caddy (I've done it behind Nginx before), but my reading of the Caddy source code, suggests that it may be? Essentially, it requires that the validition of the TLS cert is skipped, because a self signed cert won't be trusted by Caddy by default.

TBH, I have no idea if/how that is defined in the config though? Random guess is something like this?:

concrete.domain.example {
        reverse_proxy 192.168.0.xxx:443
        insecure
        encode gzip zstd
}

Or perhaps one of these?:

        insecure true
        insecure yes

I am only guessing though, so you may need to consult the Caddy docs and/or Caddy community to get guidance on the exact config layout. (Or just exclude this option).

This pathway is still pretty simple and a clear improvement as it means that the traffic (between Caddy and Concrete) will be encrypted. So even if someone malicious is snooping on your network, they won't be able to snoop your password. However, it's still far from perfect as there is still no guarantee that the backend server actually is your Concrete server (so a MITM attack would again be trivial).

3. "proper" (e.g. LE) https (port 443)

3a. Concrete get's it's own cert

This option will require that your Concrete server has it's own legitimate CA signed cert (e.g. from Let's Encrypt). Not considering how you get the cert, this is a super simple option and once configured, should "just work" (similar to vanilla http). That will be as secure as you can get, as all traffic between Caddy and Concrete will be encrypted and if someone tries to do a MITM, the connection will fail (because there would be an invalid intermediate cert).

On the downside, your Concrete server will need to get it's own cert from LE. Whilst it doesn't make Caddy completely redundant (it's still providing the reverse proxy) it does somewhat minimise the value of centrally managed https termination (because you still need to manage the local LE cert on Concrete). The only ACME validation path supported by Confconsole in v17.x is HTTP-01 - which requires your server be publicly available via port 80. You could do that in Caddy I'm sure (i.e. reverse proxy ports 80 (for LE validation) & port 443 (for Concrete content). In the upcoming v18.x, DNS-01 ACME cert validation is an option. That is better IMO because you don't need to reverse proxy port 80, but it still defeats the idea of centrally managed TLS.

3b. cert copied from Caddy

A variation on the above would be to copy the valid Let's Encrypt certs from your Caddy instance to the Concrete instance. AFAIK that is essentially what Timmy is doing. Whilst this should work fine, the most common config is to get a combined cert on the host (i.e. Caddy) and use the same cert for all content being served. It's probably unlikely to ever be an issue, however having a unique certificate on each backend is the only way to ensure that the backend you are connecting to actually is the Concrete server. To ensure that, you'd need to get an individual cert for each backend server.

Either way...

Regardless, I imagine that the Caddy config for this option (i.e. LE cert for back - inc the variation) would be very similar to the first config example I gave (except via hostname on port 443):

concrete.domain.example {
        reverse_proxy concrete.domain.example:443
        encode gzip zstd
}

Note that you will need to create a hosts file entry for the domain (pointing to the private LAN IP). Otherwise Caddy will probably do a DNS lookup and then use it's own public IP, thus creating a never ending loop.

4. Caddy CA signed https (port 443)

TBH, this is me speculating on how flexible Caddy's CA (certificate authority) setup is. It appears to me that Caddy ships with the requirements for this pathway OOTB, but I'm not sure if they can easily be bent to do it this way? For reference, the "bending" I'm referring to is using the Caddy CA signed certs for the backend too. The bit I'm not 100% sure of is whether Caddy will check it's own CA when validatinig the cert of your backend servers?

FWIW I have a vague idea of how you would go about this with Nginx and OpenSSL, but I have zero experience with Caddy, so you'll definitely need to check the docs and/or ask on their forums if this doesn't "just work".

Assuming that what I think is possible, this last path has same advantages as #3, but without the need to get LE certs on your Concrete server (although I guess it hardly matters where they come from if you still need to copy them across). Another advantage is that you can set a long expiry time, so you only need to copy the cert once (not every 3 months - like LE certs require). You can also use issue certs for unique internal domain names and even IP addresses potentially.

Bottom line...

Please note that I haven't explicitly gone through and tested all this, but I feel fairly confident that what I've written is at least generally correct (there may be some details that require tweaks). Hopefully it's of some value to you?

As you can see, there are a range of options and none of them are "right"! It all comes down to what works for you and what your risk profile and risk appetite are.