SSL & Fog http - curl failed to verify the legitimacy of the server and therefor could not establish a secure connection to it.

george1421

@maverickws said in SSL & Fog http - curl failed to verify the legitimacy of the server and therefor could not establish a secure connection to it.:

works fine with this configuration for SystemRescueCD

First it was my mistake equating SystemRescueCD with Hirens. I read very quickly and made the inaccurate connection.

As for using curl, I’m not sure what you are truly doing here. I’m interested in seeing if you can get curl to trust the srvpublic.crt file you mentioned that way it can draw files from the FOG server. But in my tutorial I’ve never used curl since iPXE will do what I need.

Back to my original post what does your param block look like or what method worked to download the SystemRescueCD in the past, we may need to translate it over to iPXE command format.

maverickws

@george1421 I used a RockyLinux minimal install, installed the Development Tools (dnf groupinstall Development Tools) and the epel repo.

No packages were manually installed. Everything came from the FOG installer. (used git to clone the repo, master branch)

I’m trying to understand which curl is being used to download the images. What exactly is the certificate store that curl is using?

FOG is listening on port 80 and IS redirecting to https.
This is the http section of my fog.conf from /etc/httpd/conf.d

<VirtualHost *:80>
    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9000/"
    </FilesMatch>
    ServerName 10.0.0.1
    ServerAlias fog.servers.domain.io
    DocumentRoot /var/www/html/
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    RewriteRule /management/other/ca.cert.der$ - [L]
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]
</VirtualHost>

As for using curl, I’m not sure what you are truly doing here. I’m interested in seeing if you can get curl to trust the srvpublic.crt file you mentioned that way it can draw files from the FOG server. But in my tutorial I’ve never used curl since iPXE will do what I need.

Back to my original post what does your param block look like or what method worked to download the SystemRescueCD in the past, we may need to translate it over to iPXE command format.

About curl, I’m not sure either. That’s really what I was trying to figure out.
Because I don’t think that the curl being used is binary from the FOG server. So I don’t see how it would either way trust that certificate. I am thinking the curl is loaded from the boot image loaded by FOG.

The param block looks exactly like the tutorial, only the paths after {fog-ip} have been edited to match our env, which as I mentioned is simply instead of SystemRescueCD its sysresccd /boot /x86_64 respecting the original files locations on the CD.

I believe that if I hadn’t enabled SSL the boot would be working just fine actually.

george1421

@maverickws OK lets take a step back from the edge here <joke>

I just downloaded the SystemRescueCD iso image. I don’t have a lot of time at the moment to test this, but I see what they are doing and I found they are using syslinx syntax.

This is the config file of interest

LABEL sysresccd_nbd
TEXT HELP
Boot the SystemRescue live medium (Using NBD).
It allows you to install Arch Linux or perform system maintenance.
ENDTEXT
MENU LABEL Boot SystemRescue (NBD)
LINUX boot/x86_64/vmlinuz
INITRD boot/intel_ucode.img,boot/amd_ucode.img,boot/x86_64/sysresccd.img
APPEND archisobasedir=sysresccd archisolabel=RESCUE901 archiso_nbd_srv=${pxeserver} iomem=relaxed
SYSAPPEND 3

LABEL sysresccd_nfs
TEXT HELP
Boot the SystemRescue live medium (Using NFS).
It allows you to install Arch Linux or perform system maintenance.
ENDTEXT
MENU LABEL Boot SystemRescue (NFS)
LINUX boot/x86_64/vmlinuz
INITRD boot/intel_ucode.img,boot/amd_ucode.img,boot/x86_64/sysresccd.img
APPEND archisobasedir=sysresccd archiso_nfs_srv=${pxeserver}:/run/sysresccd/bootmnt iomem=relaxed
SYSAPPEND 3

LABEL sysresccd_http
TEXT HELP
Boot the SystemRescue live medium (Using HTTP).
It allows you to install Arch Linux or perform system maintenance.
ENDTEXT
MENU LABEL Boot SystemRescue (HTTP)
LINUX boot/x86_64/vmlinuz
INITRD boot/intel_ucode.img,boot/amd_ucode.img,boot/x86_64/sysresccd.img
APPEND archisobasedir=sysresccd archiso_http_srv=http://${pxeserver}/ iomem=relaxed
SYSAPPEND 3

This shows 3 different methods of starting up the systemrescue cd. One by pxe (tftp), one by nfs, and one by http.

So lets take this syslinux syntax and convert it over it iPXE (what fog uses)

LABEL sysresccd_nbd
TEXT HELP
Boot the SystemRescue live medium (Using NBD).
It allows you to install Arch Linux or perform system maintenance.
ENDTEXT
MENU LABEL Boot SystemRescue (NBD)
LINUX boot/x86_64/vmlinuz
INITRD boot/intel_ucode.img,boot/amd_ucode.img,boot/x86_64/sysresccd.img
APPEND archisobasedir=sysresccd archisolabel=RESCUE901 archiso_nbd_srv=${pxeserver} iomem=relaxed
SYSAPPEND 3

The translated params section of the fog iPXE menu would look like this: understand this below will not work out of the box because the files are not in the right places on the FOG server. But in general this is the flow

kernel tftp://${fog-ip}/boot/x86_64/vmlinuz
imgfetch  tftp://${fog-ip}/boot/intel_ucode.img
imgfetch  tftp://${fog-ip}/boot/amd_ucode.img
imgfetch  tftp://${fog-ip}/boot/x86_64/sysresccd.img
imgargs vmlinuz archisobasedir=sysresccd archisolabel=RESCUE901 archiso_nbd_srv=${fog-ip} iomem=relaxed
boot || goto MENU

There are examples of how this is done on that monster tutorial I referenced before (tftp, nfs, and http image loading).

As I said I don’t have time at the moment to work out the exact step by step but it surely looks like a possible thing.

I do have a reference to systemrescue on that tutorial page here: https://forums.fogproject.org/post/112052 Its from 2018. It looks like a similar program.

maverickws

@george1421 Please allow me to thank you for your time and effort following up on this topic.

I had seen that tutorial also, the problem with it is that references a quite old version of SystemRescue (5.x) while we’re currently at 9.01 and there are many critical differences between them. The tutorial for SystemRescue 8.1 is very similar tho, that’s why I followed it.

So basically what you’re suggesting is that, instead of http I use the network block device method.
From what I’m able to see, no NBD server is installed with the FOG server, do you confirm?

I understand that this is a workaround proposition to get SystemRescueCD to work/boot. But at the same time we’re digressing from the original issue, which is CURL and it’s trust chain. If I apply this workaround, I’ll still be unable to use http and will have to always resort to nbd, AND will have to configure the nbd service first, correct?

I had an alternative method in mind, which would be adding a rule to disable the https redirect for specific paths. (like when trying to reach anything within /utils)

george1421

@maverickws said in SSL & Fog http - curl failed to verify the legitimacy of the server and therefor could not establish a secure connection to it.:

But at the same time we’re digressing from the original issue, which is CURL and it’s trust chain. If I apply this workaround,

I’ll have to spin up a fog server in my dev environment when I get home tonight to test https and http redirects. Since I haven’t needed to do this before I can’t say off the top of my head. I think there is an answer to this issue if I can spend some time thinking it through. At the very least we can add a new virtual site to the apache configuration on a different port than 80 to do what you want, but again I haven’t put too much thought into it at the moment.

Sebastian Roth

@maverickws said in SSL & Fog http - curl failed to verify the legitimacy of the server and therefor could not establish a secure connection to it.:

About curl, I’m not sure either. That’s really what I was trying to figure out.
Because I don’t think that the curl being used is binary from the FOG server. So I don’t see how it would either way trust that certificate. I am thinking the curl is loaded from the boot image loaded by FOG.

I have to admit I have not had the time to play with it but with some good background in FOG and PXE booting distros I am sure it’s curl included in the SystemRescueCD ISO.

So working around this you have a few options:

Disable HTTP->HTTPS redirect for certain URLs
Extract the ISO, add --insecure to the curl call and re-master the ISO -> probably a fair amount of work, I haven’t done it before
See if you can PXE boot it via NFS rather than HTTP

maverickws

@george1421 I have time actually this is not the most urgent matter at hand. (and hopefully I won’t get struck by the pressing need of it in the next days).

I think I’d rather have it configured with a <Directory> block inside the VirtualHost preventing the HTTPS redirect than making a new virtual site to apache listening on another port. This is just as I feel this is a simpler option.

I’ve been trying a few stances but haven’t got it to work it.

I have a question though:
The boot process is:

iPXE gets undionly.kpxe;
configures devices,
downloads:

tftp://10.0.0.1/default.ipxe
https://10.0.0.1/fog/service/ipxe/boot.php
https://10.0.0.1/fog/service/ipxe/bg.png

And it loads the boot menu.
So here we’ve used https without any issue, I dunno what util is being used for the download (curl, wget, other).

I select SystemRescueCD 9.01 from the menu, it downloads:

tftp://10.0.0.1/utils/sysresccd9.01/boot/x86_64/vmlinuz
tftp://10.0.0.1/utils/sysresccd9.01/boot/intel_ucode.img
tftp://10.0.0.1/utils/sysresccd9.01/boot/amd_ucode.img
tftp://10.0.0.1/utils/sysresccd9.01/boot/x86_64/sysresccd.img
docache...
Probing EDD (edd=off to disable)... ok
[    3.482042] initramfs unpacking failed: invalid magic at start of compressed archive
:: running early hook [udev]
Starting version 250.3-3-arch
:: running early hook [archiso_pxe_nbd]
:: running hook [udev]
:: Triggering uevents...
[    3.739314] vid-5659: 19 xenbus_dev_probe on device/vbd/5696
:: running hook [memdisk]
:: running hook [findroot]
:: running hook [archiso]
:: running hook [archiso_loop_mnt]
:: running hook [archiso_pxe_common]
Attempting to configure network interface eth0 ...
IP-Config: eth0 hardware address 2e:00:7f:d3:ab:3c mtu 1500 DHCP
IP-Config: eth0 guessed broadcast address 10.0.0.255
IP-Config: eth0 complete (from 10.0.0.252):
 address: 10.0.0.70        broadcast: 10.0.0.255       netmask: 255.255.255.0
 gateway: 10.0.0.254       dns0     : 10.0.0.254       dns1   : 0.0.0.0
 host   : testsrv01
 domain : servers.domain.io
 rootserver: 10.0.0.1 rootpath:
 filename  : undionly.kpxe
SUCCESS: Network interface eth0 has been successfully configured
:: running hook [archiso_pxe_nbd]
:: running hook [archiso_pxe_http]
:: running hook [archiso_pxe_nfs]
:: running hook [encrypt]
:: Mounting /run/archiso/httpspace (temps) filesystem, size='75%'
Downloading 'http://10.0.0.1/utils/sysresccd9.01/sysresccd/x86_64/airootfs.sfs'
  % Total    % Received % Xferd  Average Speed   Time   Time    Time  Current
                                 Dload  Upload   Total  Spent   Left  Speed
100   253  100   253    0     0   2555      0 --:--:-- --:--:-- --:--:-- 2581
curl: (60) SSL certificate problem: self signed certificate in certificate chain.
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.
ERROR: Downloading 'http://fog.servers.domain.io/utils/sysresccd9.01/sysresccd/x86_64/airootfs.sfs'
  Failing back to interactive prompt
  You can try to fix the problem normally, log out when you are finished
sh: can't access tty: job control turned off
[rootfs ]#

My question is, is this “rootfs” loaded from FOG, or from the files loaded already from sysresccd?
I have been assuming this is from the SystemRescueCD image, as initially there was no issue for iPXE to get to https:// … boot.php.

Sebastian Roth

@maverickws said in SSL & Fog http - curl failed to verify the legitimacy of the server and therefor could not establish a secure connection to it.:

My question is, is this “rootfs” loaded from FOG, or from the files loaded already from sysresccd?

The later I am sure. See my post an hour ago.

maverickws

@sebastian-roth Hi there thank you too for following up on this!

Sorry I guess I missed your reply while I was replying to george!

I was thinking too that it was SRCD’s curl, makes sense given the evidence so far.
Currently I’m going for the first suggested option:

Disable the HTTP->HTTPS redirect for certain URLs

I have made a test only but haven’t been successful to put it to work. Basically I’ve tested adding a line to the VirtualHost Block below RewriteEngine On:

RewriteEngine On
    RewriteRule ^(utils)($|/) - [L]
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    RewriteRule /management/other/ca.cert.der$ - [L]
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]

Trying to figure this one out better.

george1421

@maverickws said in SSL & Fog http - curl failed to verify the legitimacy of the server and therefor could not establish a secure connection to it.:

Probing EDD (edd=off to disable)... ok
[    3.482042] initramfs unpacking failed: invalid magic at start of compressed archive
:: running early hook [udev]

Right here is where vmlinuz takes over control of the target computer. At this point FOG and ipxe is out of the picture. So the rescue CD is in control of the workstation. Also the curl command is coming from inside the initrd (i assume sysresccd.img) so anything you do to fog (outside the apache settings) is out of the picture. The root CA certificate will need to be added to the sysresccd.img file since that is where curl is coming from.

In my opinion, I would turn off https on the fog server so this app will play better, but do what fits your organization best.

maverickws

SOLVED!

Solved it by adding the line RewriteCond %{REQUEST_URI} !^/utils to the VirtualHost block at /etc/httpd/conf.d/fog.conf so it looks like this now:

<VirtualHost *:80>
    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9000/"
    </FilesMatch>
    ServerName 10.0.0.1
    ServerAlias fog.servers.domain.io
    DocumentRoot /var/www/html/
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    RewriteRule /management/other/ca.cert.der$ - [L]
    RewriteCond %{HTTPS} off
    RewriteCond %{REQUEST_URI} !^/utils
    RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]
</VirtualHost>

@george1421 hi and once again let me thank you for your time.
I just managed to get over the problem and disabled the HTTPS redirect for the /utils path.
SystemRescue loaded just fine.

I would suggest, maybe, adding this rule by default when we enable SSL on the fog server, and having therefor a specific path to put boot files that could be blocked by curl’s certificate check.

SSL & Fog http - curl failed to verify the legitimacy of the server and therefor could not establish a secure connection to it.

168

11.6k

17.1k

154.6k