FOG behind reverse proxy
-
Hi,
I am looking to use the Let’s Encrypt wildcard Certs with a number of the sites we host (even those used internally) and was planning on putting them all behind a reverse proxy since we can’t automate our DNS and need to allow Certbot to communicate with Lets Encrypt’s servers. If we have an internal DNS name for fog that we put into the client (fog.domain.org/fog) will it be a problem if it is passing through the reverse proxy?
Thanks
-
@astrugatch Let me start by saying that this is kind of an advanced setup that I guess you are one of the first people considering this I think. While I think it’s a good concept I am fairly sure you’ll run into a couple of obstacles that won’t make it easy for you.
Before I start to get into the details I might ask you what is your exact aim? I see you asked about SSL in the forums a while ago. But I am not sure which way you decided to go and what stage you are at. Is your aim to have the FOG server HTTPS only with Let’s Encrypt cert? Or do you simply want HTTPS with Let’s Encrypt cert for the webUI? I just ask because different aims lead you different ways and some are harder or even impossible to go while others can be achieved.
Here is the story why I think you aim matters a lot:
When the new fog-client came to life years ago (Summer 2014 I think) HTTPS was not as wide spread as it is today. But still the fog-client was made to use encryption to secure the communication. It’s not general HTTPS (SSL/TLS over HTTP) but a self engineered communication protocol based public/private key encryption using certificates just as HTTPS is. It actually uses exactly those certificates that can be used for HTTPS but follows a different protocol (using state of the art AES 256 encryption)! Back then I was not as heavily involved into FOG yet and I lack the information on why the developers decided to go this way. I am sure it was for good reasons! Just keep that in mind.
So when you install the client it asks for server address (IP or DNS name) and web root. Now it connects to the FOG server, downloads the CA certificate, verifies it and locks into that as root of verification (process is called pinning) for all later (encrypted) communication. As mentioned the communication is done over HTTP (http://fog.domain.org/fog) but the contents are encrypted. Now if you change the certificates (CA and server cert) on your FOG server while some of your fog-clients have already been pinned to the old one the communication will break. You would need to re-pin (not sure if that can be automated) or re-install the fog-client to all your hosts to make them use your new CA cert the root of verification.
And even if you decide to re-do it all I need to inform you that we’d have to compile a fresh fog-client version for you. As of now you can only use certificates from a self signed CA as the fog-client checks the subject of the CA certificate to be “FOG Project” when it does the pinning. So it won’t pin to the Let’s Encrypt CA certificate.
There is one more thing I want to bring into play. Beside all the fog-client encryption stuff you can still make the fog-client use HTTPS (double encrypted sort of). You can switch to HTTPS after fog-client installation changing the parameter
HTTPSfrom 0 to 1 inC:\Program Files (x86)\FOG\settings.json. But as you can’t switch off the fog-client specific encryption you’d still run into the problems mentioned above. AFAIK the pinning is done via HTTP and we’d need to change that in the fog-client code as well if you want to go HTTPS only. Not sure if it’s worth going that route.The things mentioned so far don’t stop you from using Let’s Encrypt certificates for the web UI though. You need to sort of separate web UI from from fog-client communication certificate-wise. Probably best to use different vhost definitions as you were discussing with Tom in the other forum thread.
Again, this is just an overview of what I think needs to be considered when you want to use a reverse proxy. I might even have missed something here. As well I am writing this just form the top of my head as I don’t have the time to go through the code and even test things right now.
-
Thanks for the super thorough reply. I wasn’t looking to encrypt the client traffic, just the web UI, but knowing that them having the same hostname and thereby passing through the ReverseProxy was my concern. The separate vhost or DNS entry might be better, one for the web UI and one for the clients to use, so I can leave the CA certs untouched. then the clients can go directly to the fog.domain.com/fog and the webUI can be something like fogmgmt.domain.com/fog
I do think support for external CAs would be good in the future for the client as well but that isn’t my current goal.
Thanks for all your help!
-
@astrugatch said:
I do think support for external CAs would be good in the future for the client as well but that isn’t my current goal.
I thought about this a couple of times when I wrote that post. But I have not come to a nice conclusion yet. I mean supporting external CAs within the fog-client would be just a minor code change - no trouble. But actually moving an existing environment from one CA to another one is a tough job I reckon. And on the other hand I wonder if it’s advisable to do because someone might misuse that to trick clients into trusting a different (fake) server. Not very common as an attack vector within an internal network but I am not sure if we want to open such a vector yet.
-
It might be worth researching how services like JAMF support external CAs for their enrolled clients.
By default JAMF works the way fog works with a selfsigned cert from its own CA but they do have support for certain Public CAs. -
@astrugatch Thanks for pointing us to JAMF as example for CA/cert management with clients. It’s been a while but I had this on my list of things to do/check and now I got to it.
JAMF can be setup to use different CAs/certs: https://docs.jamf.com/10.0.0/jamf-pro/administrator-guide/PKI_Certificates.html
That page led me to the so called Simple Certificate Enrollment Protocol (SCEP) which does handle some of the things that come with certificates. But the initial problem of establishing a CA trust is still the same - described in section 5.5:
Before any transaction begins, end entities have to get the CA (and possibly RA) certificate(s) first. Since the requester may have no CA certificates or CA public keys at all, this message can not be encrypted and the response must be authenticated by out-of-band means.
[…]
If the requester does not have a certificate path to a trusted CA certificate, this fingerprint may be used to verify the certificate, by some positive out-of-band means, such as a phone call.Let’s assume the situation where the clients already trust the built-in self-signed FOG server certificate. We could use that to establish a trusted communication channel and send the new CA certificate to the clients and tell them to install and trust it. Definitely a possible route. But what about clients that are switched off at that moment? We would need allow clients to use both CA trusts over a period of time till all of them have moved to the new one. This is definitely possible but complex to implement and I wouldn’t find the time although I find it interesting and challenging.
Trying to digg a little deeper if and how JAMF has solved the above mentioned trust problem when moving from one CA to another I found those notes in the manual:
Note: By default, Jamf Pro uses the signing and CA certificates for the Jamf Pro built-in CA. You must replace these certificates with the ones for the external CA when you initially set up the integration.
and
Note: If you need to make changes to your organizational or third-party CA in Jamf Pro, it is recommended that you contact your Jamf account representative. Changes to the PKI could lead to re-enrolling the mobile devices in your environment.
Now let’s look at the other situation where no clients have been pinned to the FOG server yet. If you re-compile the client to check on a different name in the CA cert you can happily use external CA certs without an issue.