Posts made by ggiesen

ggiesen

I worked around this temporarily by adding the following to /etc/httpd/conf.d/fog.conf:

--- a/fog.conf        2022-09-07 22:51:29.354392458 +0000
+++ b/fog.conf    2022-09-08 15:05:58.172516747 +0000
@@ -9,6 +9,8 @@
     RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
     RewriteRule .* - [F]
     RewriteRule /management/other/ca.cert.der$ - [L]
+    RewriteCond %{HTTP_HOST} ^([1-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}$     
+    RewriteRule (.*)  https://fog.example.com/$1 [L,R=301]
     RewriteCond %{HTTPS} off
     RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]
 </VirtualHost>

This is not a permanent fix, as it basically just redirects traffic to the IPv4 address of the FOG server to the hostname, and creates a dependency on IPv4 (will break in an IPv6-only setup), but works for now.

ggiesen

@ggiesen said in FOG Client with CA-issued TLS certificate:

I’ve rebuilt the iPXE clients and they work just fine.

I should note when I rebuilt the iPXE clients, I patched them with this patch: https://github.com/ipxe/ipxe/pull/116 to work around issues with long certificate chains.

ggiesen

So I’ve made some progress. I used the Reset Encryption Data on the Host > General page, and now it it looks like I face a new problem:

------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 2022-09-07 10:24:03 PM Client-Info Client Version: 0.12.0
 2022-09-07 10:24:03 PM Client-Info Client OS:      Windows
 2022-09-07 10:24:03 PM Client-Info Server Version: 1.5.9
 2022-09-07 10:24:03 PM Middleware::Response Success
 2022-09-07 10:24:03 PM SnapinClient Running snapin Chrome Enterprise
 2022-09-07 10:24:03 PM Middleware::Communication Download: http://192.0.2.10//fog/service/snapins.file.php?mac=00:05:9A:AA:BB:CC|88:A4:C2:AA:BB:CC|F4:A4:75:AA:BB:CC|F4:A4:75:AA:BB:CC|F6:A4:75:AA:BB:CC|F4:A4:75:AA:BB:CC&taskid=14
 2022-09-07 10:24:03 PM Middleware::Communication SSL connection error: RemoteCertificateNameMismatch
 2022-09-07 10:24:03 PM Middleware::Communication ERROR: Could not download file
 2022-09-07 10:24:03 PM Middleware::Communication ERROR: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
 2022-09-07 10:24:03 PM SnapinClient C:\Program Files (x86)\FOG\tmp\googlechromestandaloneenterprise64.msi
 2022-09-07 10:24:03 PM Middleware::Communication URL: https://fog.example.com/fog/service/snapins.checkin.php?taskid=14&exitcode=-1&mac=00:05:9A:AA:BB:CC|88:A4:C2:AA:BB:CC|F4:A4:75:AA:BB:CC|F4:A4:75:AA:BB:CC|F6:A4:75:AA:BB:CC|F4:A4:75:AA:BB:CC&newService&json
------------------------------------------------------------------------------

The SnapIn client appears to be trying to talk to the web server using HTTP and on the IP address rather than the FQDN. Any way to fix this?

ggiesen

I also attempted the workaround tried here: https://forums.fogproject.org/post/145634 but now encounter this:

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 2022-09-07 10:04:25 PM Client-Info Version: 0.12.0
 2022-09-07 10:04:25 PM Client-Info OS:      Windows
 2022-09-07 10:04:25 PM Middleware::Authentication Waiting for authentication timeout to pass
 2022-09-07 10:04:25 PM Middleware::Communication Download: https://fog.example.com/fog/management/other/ssl/srvpublic.crt
 2022-09-07 10:04:25 PM Data::RSA FOG Server CA cert found
 2022-09-07 10:04:25 PM Middleware::Authentication Cert OK
 2022-09-07 10:04:25 PM Middleware::Authentication No token found at C:\Program Files (x86)\FOG\token.dat, this is expected if the client has not authenticated before
 2022-09-07 10:04:25 PM Middleware::Authentication ERROR: Could not get security token
 2022-09-07 10:04:25 PM Middleware::Authentication ERROR: Could not find file 'C:\Program Files (x86)\FOG\token.dat'.
 2022-09-07 10:04:25 PM Middleware::Communication POST URL: https://fog.example.com/fog/management/index.php?sub=requestClientInfo&authorize&newService
 2022-09-07 10:04:26 PM Middleware::Response Invalid security token

I did the following:

Copied my server certificate (+ intermediate certs) to /etc/pki/tls/certs/fog.example.com.crt, server private key to /etc/pki/tls/private/fog01.egate.net.key, and CA certificate (+ intermediate certs) to /var/www/html/fog/management/other/sectigo_ca_bundle.crt.

I modified 3 lines in /etc/httpd/conf.d/fog.conf:

    SSLCertificateFile /etc/pki/tls/certs/fog.example.com.crt
    SSLCertificateKeyFile /etc/pki/tls/private/fog.exampe..com.key
#    SSLCACertificateFile /var/www/html/fog//management/other/ca.cert.pem

I restarted apache and rebuilt iPXE with:

$ buildipxe.sh /var/www/html/fog/management/other/sectigo_ca_bundle.crt

There is no token in C:\Program Files (x86)\FOG\token.dat (file does not exist).

Any thoughts?

ggiesen

I have my FOG server (1.5.9) configured with a Sectigo-issued TLS certificate per https://wiki.fogproject.org/HTTPS#Custom_CA_and_certificates using option #2 (Use your custom CA for Apache configuration only but stick to FOG CA for fog-client internal encryption.)

Per the instructions I’ve placed my CA certificate chain (3 certificates), server certificate, and private key at /var/www/html/fog/management/other/ca.cert.pem, /var/www/html/fog/management/other/ssl/srvpublic.crt, and /opt/fog/snapins/ssl/.srvprivate.key, respectively.

I’ve rebuilt the iPXE clients and they work just fine. When I install FOG client (0.12.0) with HTTPS enabled, it validates and PINs the certificate as well. However, when it comes to the client actually connecting to the FOG server, I receive the following error in the log:

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 2022-09-07 4:01:26 PM Client-Info Version: 0.12.0
 2022-09-07 4:01:26 PM Client-Info OS:      Windows
 2022-09-07 4:01:26 PM Middleware::Authentication Waiting for authentication timeout to pass
 2022-09-07 4:01:26 PM Middleware::Communication Download: https://fog.example.com/fog/management/other/ssl/srvpublic.crt
 2022-09-07 4:01:27 PM Data::RSA FOG Server CA cert found
 2022-09-07 4:01:27 PM Data::RSA ERROR: Certificate validation failed
 2022-09-07 4:01:27 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Thumbprints did not match.
 2022-09-07 4:01:27 PM Middleware::Authentication ERROR: Could not authenticate
 2022-09-07 4:01:27 PM Middleware::Authentication ERROR: Certificate is not from FOG CA

Apache is currently configured to redirect all HTTP requests to HTTPS (and I’d prefer to keep it that way). How do I go about correcting this so that the FOG client and actually connect?

I wouldn’t be opposed to migrating FOG client-only connections to HTTP (since it’s protected already) but would prefer not to give up my HTTPS redirection for UI connections.

ggiesen

I’ve nearly completed being able to automate the process of installing FOG without any human intervention, but one obstacle that remains is being able to install plugins (specifically the LDAP plugin). Is there any method (either via API or CLI) to install plugins programatically?