• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved
    General Problems
    3
    19
    7.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • george1421G
      george1421 Moderator @maverickws
      last edited by 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.:

      I can’t find ca_root_pub.cer what should its location be?

      That was an example of the root certificate I needed to import so that my proxy ssl inspection worked (not related to FOG). The path and directory structure was for debian 10. If you are using something else (though it looks from your apache path debian based) (edit: I just looked at your curl output closer and you are using rhel based system) you will need to use what is proper for your OS. This was just an example to get you started.

      FWIW, I don’t use https with my fog server so I’m only guessing that port 80 is not configured. The netstat command will prove it one way or another. I can look into it, but I don’t think fog does a http->https redirect, but I could be wrong.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      M 1 Reply Last reply Reply Quote 0
      • george1421G
        george1421 Moderator @maverickws
        last edited by

        @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.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

        1 Reply Last reply Reply Quote 0
        • M
          maverickws @george1421
          last edited by 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.

          george1421G 1 Reply Last reply Reply Quote 0
          • george1421G
            george1421 Moderator @maverickws
            last edited by

            @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.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

            M 1 Reply Last reply Reply Quote 0
            • M
              maverickws @george1421
              last edited by

              @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)

              george1421G 1 Reply Last reply Reply Quote 0
              • george1421G
                george1421 Moderator @maverickws
                last edited by

                @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.

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                M 1 Reply Last reply Reply Quote 0
                • S
                  Sebastian Roth Moderator
                  last edited by

                  @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

                  Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                  Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                  1 Reply Last reply Reply Quote 0
                  • M
                    maverickws @george1421
                    last edited by

                    @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.

                    george1421G 1 Reply Last reply Reply Quote 0
                    • S
                      Sebastian Roth Moderator
                      last edited by

                      @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.

                      Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                      Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                      M 1 Reply Last reply Reply Quote 0
                      • M
                        maverickws @Sebastian Roth
                        last edited by

                        @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.

                        1 Reply Last reply Reply Quote 0
                        • george1421G
                          george1421 Moderator @maverickws
                          last edited by

                          @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.

                          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                          1 Reply Last reply Reply Quote 0
                          • M
                            maverickws
                            last edited by 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.

                            1 Reply Last reply Reply Quote 0
                            • 1 / 1
                            • First post
                              Last post

                            153

                            Online

                            12.0k

                            Users

                            17.3k

                            Topics

                            155.2k

                            Posts
                            Copyright © 2012-2024 FOG Project