2019...a step by step activating ssl and complying iPXE with it
-
When running the installer, you should only need to use the -S argument. -C forces the installer to recreate the CA certificates. -K forces regenerating the keys for the fog server. the -K won’t be overly problematic but the -C will cause issues
the -S just forces HTTPS.
As @Sebastian-Roth as requested, please provide a photo of the tftp trying to use http instead of https
Thank you,
-
@Tom-Elliott got this. Thanks
-
@Tom-Elliott said in 2019...a step by step activating ssl and complying iPXE with it:
@marted TO get rid of the “not secure” you see, you need to download the ca.cert from the FOG Server.
https://foglabunix/fog/management/other/ca.cert.der
And put that in your machine’s trust root authority.
As to making iPXE obtain from https, you should be able to do this by reinstalling fog (assuming you didn’t reinstall when building the ipxe binaries)?Tom I have a little bit different configuration from the standard. My FOG server is in private network 192. and I have a NAT IP 132. 1:1 only for my server for accessing it from internet. Even with certificate installed it says that the certificate is only for 192.168 and name foglabunix and not for my address 132.208, which is normal. How can i pass to the certificate my second IP 132.208?
Is there a way to add it in fogconfig file in the variable ipaddress both with the private IP or there is other way?
By the way in MAC OS when I installed the certificate, even with 132.208 it accepted it and I have a SSL connection with no error.
-
@marted why not access the fog server using foglabunix? The cert is valid for that name
-
@Tom-Elliott I run the installation only with -S and root like @Sebastian-Roth Sebastian offered. The installation passed with no problems. Monday morning will try the boot and will post it here
-
@Tom-Elliott it doesn’t work
it passed only with the IP NAT 132.208
-
@marted can you add a dns entry on the nat side to get you access? For internet proper links I wouldn’t recommend using the fog ca, you should probably get a proper certificate from a 3rd party to present for internet based sites.
-
@Tom-Elliott if I get a 3rd party certificate which I can do, how can I replace the fog certificate?
-
@Tom-Elliott even better, use a reverse proxy for internet to redirect into your internal network and present the certificate at the reverse proxy. This way you can use a dns name that points to a machine within your dmz, that can be restricted to internal machines. And you aren’t putting your actual fog server in any risk as all things requesting your fog server from the internet won’t actually give access to your fog server files. At least not by simply pointing to your nat side ip. You could, essentially, get rid of the nat network for your fog server in this way too.
-
@marted you tell Apache using a namedvirtualhost config. So 192.x and foglabunix are handled by the fog ca certificate and the nat ip request is handled by the 3rd party certificate.
-
@Tom-Elliott we have a restrict proxy installed in our university. To access 132.208 network to the university I need to use private VPN configured and managed by the university. Once I activated the VPN with a private password now I have access to my 132.208 NAT. without VPN nobody from the network cannot access it. All I show you is with a VPN to the university ON. The point is to use 132.208 with VPN on and ssl not to use a computer in the lab 192.168
-
@marted if you’re connecting over vpn, why would need to assign a public ip to the fogserver?
I guess I don’t understand the complexity involved here. If you have to access vpn to reach the fog server, why would you access it over public up spaces? VPN puts you to the internal network. You should be able to access the machine locally when connecting over VPN.
I understand security and all but this seems more complicated than secure.
-
@marted Your setup is kind of special so there is no common solution to it. But we can try some workaround:
- edit
/opt/fog/.fogsettings
and change the linehostname=foglabunix
tohostname=132.208.x.y
- re-run the installer this time using the command line parameters to re-create CA keys:
./installfog.sh -S -C -K
- download and import the newly generated https://132.208.x.y/fog/management/other/ca.cert.der into your browser
- edit
-
Understand:
VPN is intended to allow external access to internal resources. Maybe I don’t understand your situation. That’s okay, I don’t need to, but this is seeming to be extremely convoluted.
-
You have local private spaces machines who access fog via local private calls: eg foglabunix or 192.168.x.x
-
You have VPN to access public up space with no DNS and only accessible through VPN connectivity? Why this? If the purpose of the VPN public IP is to get access to the fog server, why do VPN to a public IP that’s only accessible when VPN is enabled? Why not have the VPN connect so you can reach the local resources as they stand.
-
Reverse proxy != to proxy. It works in reverse. Meaning instead of all internal to external traffic being filtered to it, all external requests come to it and send to internal resources. It shouldn’t require login as it’s meant to be a central request point. Meaning it doesn’t give away local resources but provides the local resources you are requesting through the reverse proxy. So you don’t run risk of ssh attacks to multiple machines and whatnot.
-
-
@Sebastian-Roth thanks for the complete explanation about reverse VPN. Maybe me with my poor English, I’m not capable to explain you in details like I want the network configuration in the university (unfortunately we speak french here in Quebec, Canada better than English:) ), but I truly understand what you wrote and I appreciate the time you spent for that.
Everything works fine now, I was capable to generate a second certificate with 132.208 and I installed in my access computer. Thanks again. -
@Sebastian-Roth I reinstalled With the options you suggested -S -K -C and web aces fro my home worked fine but this morning when I tried to boot a computer in my lab it gives permission denied error. I checked the error on the website of iPXE it says problem with the certificate. I reinstalled the server two times once only with -S only (same error) and second time with -S -C - K I thought maybe iPXE was not compiled well , but still same error. Before l’installation I fixed the .fogsetings with the real IP 192.168…
the permissions are correct for iPXE in var/www
Any suggestions? Thanks!
-
@marted Manually run the compile script to see if it throws any errors:
cd fogproject/utils/FOGiPXE ./buildipxe.sh
-
@Sebastian-Roth no errors . Do I have to copy the new files compiled manually to /tftpboot ?
-
@Sebastian-Roth reinstalled complitly FOG like http (I deleted everything , left only /images and users). Works fine
It boots well in http. reinstall again only with -S , again the same problem.
output from https://192.168.149.43/fog/service/ipxe/boot.php in web broser . I even changed the permissions of the boot.php file on the server but no effect#!ipxe set fog-ip 192.168.149.43 set fog-webroot fog set boot-url https://${fog-ip}/${fog-webroot} cpuid --ext 29 && set arch x86_64 || set arch i386 goto get_console :console_set colour --rgb 0x00567a 1 || colour --rgb 0x00567a 2 || colour --rgb 0x00567a 4 || cpair --foreground 7 --background 2 2 || goto MENU :alt_console cpair --background 0 1 || cpair --background 1 2 || goto MENU :get_console console --picture https://192.168.149.43/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console :MENU menu colour --rgb 0xff0000 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item --gap Host is NOT registered! item --gap -- ------------------------------------- item fog.local Boot from hard disk item fog.memtest Run Memtest86+ item fog.reginput Perform Full Host Registration and Inventory item fog.reg Quick Registration and Inventory item fog.deployimage Deploy Image item fog.multijoin Join Multicast Session item fog.sysinfo Client System Information (Compatibility) choose --default fog.local --timeout 3000 target && goto ${target} :fog.local sanboot --no-describe --drive 0x80 || goto MENU :fog.memtest kernel memdisk initrd=memtest.bin iso raw initrd memtest.bin boot || goto MENU :fog.reginput kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=https://192.168.149.43/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.149.43:/images/ storageip=192.168.149.43 loglevel=4 mode=manreg imgfetch init_32.xz boot || goto MENU :fog.reg kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=https://192.168.149.43/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.149.43:/images/ storageip=192.168.149.43 loglevel=4 mode=autoreg imgfetch init_32.xz boot || goto MENU :fog.deployimage login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param qihost 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme param sysuuid ${uuid} :fog.multijoin login params param mac0 ${net0/mac} param arch ${arch} param username ${username} param password ${password} param sessionJoin 1 isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme param sysuuid ${uuid} :fog.sysinfo kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=https://192.168.149.43/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.149.43:/images/ storageip=192.168.149.43 loglevel=4 mode=sysinfo imgfetch init_32.xz boot || goto MENU :bootme chain -ar https://192.168.149.43/fog/service/ipxe/boot.php##params || goto MENU autoboot
-
@marted said in 2019...a step by step activating ssl and complying iPXE with it:
no errors . Do I have to copy the new files compiled manually to /tftpboot ?
Yes, after manually running the compile script you need to copy the new iPXE files from
fogproject/packages/tftp/
to/tftpboot/
directory!If you use the installer it will do the copy for you.
reinstall again only with -S , again the same problem.
I am wondering if the modification I told you to test is causing the problem. As I said, your setup is special and not something many people have tried before. I will do a test install and see if it works for me.