HTTPS - Revision history

SebastianRoth at 19:32, 25 February 2020

2020-02-25T19:32:18Z

SebastianRoth: /* PXE boot */

2020-02-25T19:31:46Z

‎PXE boot

SebastianRoth: /* Known issues */

2020-02-25T19:29:42Z

‎Known issues

SebastianRoth at 19:26, 25 February 2020

2020-02-25T19:26:34Z

SebastianRoth: /* Custom CA and certificates */

2020-02-23T12:10:58Z

‎Custom CA and certificates

SebastianRoth: /* Custom CA and certificates */

2020-02-23T08:26:19Z

‎Custom CA and certificates

SebastianRoth: /* PXE boot */

2020-02-23T07:58:32Z

‎PXE boot

SebastianRoth: /* PXE boot */

2020-02-23T07:58:08Z

‎PXE boot

SebastianRoth at 18:22, 21 February 2020

2020-02-21T18:22:57Z

SebastianRoth at 20:27, 3 February 2020

2020-02-03T20:27:51Z

@@ Line 55: / Line 55: @@
 find -type f -exec cp -Rfv {} /tftpboot/{} \;</pre></blockquote>
 <blockquote><font color="red">Notice:</font> Be aware that whenever you re-run the FOG installer (update or for whatever other reason) it will overwrite your custom <code>/var/www/html/fog/management/other/ca.cert.pem</code> and <code>/var/www/html/fog/management/other/ssl/srvpublic.crt</code> file. So you will need to put those two files back in place and restart Apache. Re-compile of iPXE binaries should not be needed. Don't see this as bad intention as it's simply how the installer was created to make sure things were "correct" on every run. We will consider changing this behavior as more people will use custom CAs.</blockquote>
 == Known issues ==

@@ Line 18: / Line 18: @@
 == PXE boot ==
 When enabling HTTPS the installer compiles custom iPXE binaries for you including your personal FOG server CA certificate to be able to communicate with your secure FOG webserver. Manual adjustments should not be needed for this to work but it's quite likely this is causing trouble for some of you. If you see the error message <code>https://x.x.x.x/fog/service/ipxe/boot.php... Permission denied ...</code> on PXE booting you will be dropped to the iPXE command shell. Running the command <code>certstat</code> will show you the certificates known to iPXE at this stage:
-<blockquote>iPXE> certstat
+<blockquote><pre>iPXE> certstat
 FOG Server CA: ... [PERMANENT]
-x.x.x.x: ...</blockquote>
+x.x.x.x: ...</pre></blockquote>
 The output might differ from what you see. In this example we see that the FOG Server CA cert is embedded into the binary (permanent) and the following line shows the certificate iPXE received when contacting the webserver ''but'' it's unable to validate this cert. If it would be able to check the certificates both lines would be marked as <code>[VALIDATED]</code>. So in this case the CA cert compiled into the binary doesn't match the one which the web server certificate was signed with. More often you might just see no line starting with <code>FOG Server CA</code>. The binary was compiled with no embedded CA cert and iPXE is not to verify the cert received from the webserver.

← Older revision		Revision as of 19:29, 25 February 2020
Line 63:		Line 63:
	#: https://forums.fogproject.org/topic/12768/not-able-to-tftp-boot-invalid-argument-error		#: https://forums.fogproject.org/topic/12768/not-able-to-tftp-boot-invalid-argument-error
	#: http://forum.ipxe.org/showthread.php?tid=16998		#: http://forum.ipxe.org/showthread.php?tid=16998
		+	# When changing or re-creating (be careful!) the CA you need to make sure the rootcert part of iPXE is being rebuild.
		+	#: Either upgrade to the latest (dev) version or update your build script manually according to the [https://github.com/FOGProject/fogproject/commit/dc5b877b2604c117f235ad5f099ec55bf85c2fe0 fix you find on github].

← Older revision		Revision as of 19:26, 25 February 2020
Line 58:		Line 58:
	== Storage node setups ==		== Storage node setups ==
	TBD		TBD
		+
		+	== Known issues ==
		+	# We have seen issues with PXE booting when certificates from a certain vendor were used. Find details here:
		+	#: https://forums.fogproject.org/topic/12768/not-able-to-tftp-boot-invalid-argument-error
		+	#: http://forum.ipxe.org/showthread.php?tid=16998

@@ Line 35: / Line 35: @@
 == Custom CA and certificates ==
-In many environments certificates from an internal CA are used. While you can switch over to use your custom cert with FOG you need to be aware of possible culprits:
+In many environments certificates from an internal CA are used. While you can switch over to use your custom cert with FOG you need to be aware of possible culprits. Using a custom CA was given enough thought when HTTPS support was added to FOG and so we need to kind of build around what we currently have - FOG 1.5.8 as of writing this in Feb 2020.
+As described above the fog-client software uses internal encryption which is not the same as HTTPS. While switching to HTTPS with a custom CA does work with the fog-client by adjusting the <code>settings.json</code> you need to choose one of two ways for making the internal encryption work as well:
-TBD
+* Re-compile fog-client software to trust your custom CA:
-Using those with FOG will work if you follow a few hints. Considering the things mentioned above
+*: Replace the strings <code>FOG Server CA</code> and <code>CN=FOG Server CA</code> in [https://github.com/FOGProject/zazzles/blob/master/Zazzles/Data/RSA.cs#L131 RSA.ca] and [https://github.com/FOGProject/zazzles/blob/master/Zazzles/Middleware/Communication.cs#L302 Communication.cs] to match your custom CA common name. Then re-compile your own custom fog-client installer binaries. I won't go into any more details for now as I don't think many people will choose this path, it has other drawbacks (talking about auto upgrading) and we'll probably re-think and change this some time in the future anyway.
 == Storage node setups ==
 TBD

@@ Line 21: / Line 21: @@
 FOG Server CA: ... [PERMANENT]
 x.x.x.x: ...</blockquote>
-The output might differ from what you see. In this example we see that the FOG Server CA cert is embedded into the binary (permanent) and the following line shows the certificate iPXE received when contacting the webserver ''but'' it's unable to validate this cert. If it would be able to check the certificate the line would look like this: <code>x.x.x.x: ... [VALID]</code>. So in this case the CA cert compiled into the binary doesn't match the one which the web server certificate was signed with. More often you might just see no line starting with <code>FOG Server CA</code>. The binary was compiled with no embedded CA cert and iPXE is not to verify the cert received from the webserver.
+The output might differ from what you see. In this example we see that the FOG Server CA cert is embedded into the binary (permanent) and the following line shows the certificate iPXE received when contacting the webserver ''but'' it's unable to validate this cert. If it would be able to check the certificates both lines would be marked as <code>[VALIDATED]</code>! So in this case the CA cert compiled into the binary doesn't match the one which the web server certificate was signed with. More often you might just see no line starting with <code>FOG Server CA</code>. The binary was compiled with no embedded CA cert and iPXE is not to verify the cert received from the webserver.
 Either way you need to check your CA and certificate files on your FOG server and take a look at the installer log files in <code>fogproject/bin/error_logs/</code> to see why it didn't succeed compiling the right certificate into the iPXE binaries.
-If you can't find what's causing this you might consider re-running the FOG installer using command line options to re-generate the SSL keys and certs. '''<font style=color:red>But be aware this will break communication with all your fog-clients talking to this FOG server!</font>''' We do NOT recommend using this unless you really know what you are doing. Enough warning, here you go: <code>./installfog.sh --recreate-ca</code>
+Wrong system time can cause an issue as iPXE also checks if the embedded root CA certificate is valid based on the time. iPXE receives the current time from the BIOS / UEFI firmware and fails with <code>... Permission denied ...</code> on the HTTPS connection if it can't validate the root CA cert due to it not being valid with the wrong time set on the machine.
 == fog-client ==

@@ Line 1: / Line 1: @@
-Secure connections like HTTPS become state of the art all over the web over the years. While FOG did use secure encryption for the fog-client communication since 2016 already the FOG web UI was still using plain HTTP. Using secure HTTPS is not as easy as generating a certificate and setting Apache to use it because PXE boot also relies on HTTP(S) communication with the FOG server.
+Secure connections like HTTPS have become state of the art all over the web over the years. While FOG did use secure encryption (not HTTPS but a custom secure channel) for the fog-client communication since 2016 already the FOG web UI was still using plain HTTP. Using HTTPS is not as easy as generating a certificate and setting Apache to use it because PXE boot also relies on HTTP(S) communication with the FOG server.
-We try to make setting up a fully HTTPS-enabled FOG server more convenient and encourage people to use it but still don't consider it wise to make it the default yet because it's a complex topic (FOG server, PXE boot, fog-client). Up until now you had to use the command line switch "--force-https" to enable HTTPS but with FOG 1.5.8 this will be a question asked by the installer. Both will make FOG run in HTTPS mode:
+== Installation ==
-* The Web UI will be accessible through the new URL https://fogserver/fog/ but will also redirect requests going to the old HTTP URL.
+The installer will generate a different Apache configuration to enable HTTPS and redirect all requests from HTTP to HTTPS (minor exceptions exist). While this might sound simple there is really a lot more to it in the FOG world. Read on to learn about this in detail.
-The last point seems trivial but really is not. On PXE booting there are situation where password and username are being sent over the wire and we wanted to make this as secure as the rest. This means the iPXE binary booting on the client needs to trust your FOG webserver and we build that trust chain by embedding the CA certificate into the iPXE binary.
+== FOG web UI ==
-All fine, I have enabled HTTPS but now I have this ugly warning in my web browser saying this connection is not secure at all. Yes, this is because we can't offer certificates from an official certificate authority. Therefore we use self generated CA and certificates which are not known to your browser.
+* Firefox: Preferences -> Privacy & Security -> Certificates -> View Certificates -> Your Certificates -> Import...
-* How to get rid of the warning in my browser? -> Download https://fogserver/fog/management/other/ca.cert.pem and import to your browser (FF, Chrome, Opera) or Windows certificate management (for IE, Edge)
+== PXE boot ==
-* ...
+When enabling HTTPS the installer compiles custom iPXE binaries for you including your personal FOG server CA certificate to be able to communicate with your secure FOG webserver. Manual adjustments should not be needed for this to work but it's quite likely this is causing trouble for some of you. If you see the error message <code>https://x.x.x.x/fog/service/ipxe/boot.php... Permission denied ...</code> on PXE booting you will be dropped to the iPXE command shell. Running the command <code>certstat</code> will show you the certificates known to iPXE at this stage: