Expired Certificate Help
-
I am very green to FOG and I have inherited this from the old system admin who is now gone. We have three certificates on the clients/workstations -
- FOG Project CA - expires 2029
- FOG Project - expired last year
- FOG Server CA - expires 2029
I’ve been reading the Wiki for HTTPS (https://wiki.fogproject.org/HTTPS) and I see there are three certificates on the server -
- ca.cert.pem
- srvpublic.crt
- .srvprivate.key
When I go to each of the locations where the above certs are stored I see the original files that were generated by the FOG installer. Should I be seeing the FOG Project CA, FOG Project, and FOG Server CA instead? I see now that if you rerun the installer it will overwrite your custom certificate files. I’m guessing after upgrading from 1.5.8 to 1.5.9 these were overwritten? I guess my question is, what should I do from here? Do I need to recreate the CA’s with ./installfog.sh --recreate-ca or what else should I do?
Thanks!
-
@tlems Let me start by asking what exact issue you are facing? You have several questions but I can’t really see what is causing the trouble exactly.
I know we should’ve put in more time to document and work out that part of FOG really. But it’s just too many other things on the list and I never get to it. Anyhow… I will try to explain.
- FOG Project CA - expires 2029 ==> This CA certificate is only used within the fog-client installation process but not for communication with the FOG server at all. It’s not a unique CA. The FOG team generated this CA to sign installer binaries. The CA cert is “packed” into the installer binary and extracted on install. This is needed to verify the next fog-client SmartInstaller.exe binary that comes with a newer version of FOG and can auto-update all your machines that have fog-client installed and running. Technical background: The fog-client running as FOGService on Windows is only able to execute the SmartInstaller.exe for updating if it can verify it’s code signature using a “known” CA - which we install for you. Usually companies just pay for this kind of code signing certificates and rely on existing CAs.
- FOG Project - expired last year ==> This is the CA certificate that was used before the “FOG Project CA”, so simply put the predecessor CA cert. You can safely delete that one. Sorry the fog-client doesn’t clean up after itself.
- FOG Server CA - expires 2029 ==> This CA cert was generated on your FOG server and it’s unique to your setup. The founder of the fog-client software designed the communication channel between fog-client and FOG server to be encrypted using certificates but still transferred over plain HTTP several years ago before everyone went for HTTPS. When installing the fog-client on a machine the installer pulls this CA cert from your FOG server and “pin” to it. This is a very important piece of the puzzle to understand. If you change/overwrite the CA on your FOG server (see files explained below) an already “pinned” client will not be able to connect to the FOG server again. Understand, the fog-client does not need to use HTTPS to have a securely encrypted communication channel. But on the other hand if you enable HTTPS on your FOG server it will do double encryption. If I had a lot more time on my side I would change this part as it is fairly complex to comprehend and prone to issues. But I guess it will be a long period until we find the time or someone keen enough to join our team and get into this.
Now about the files on your FOG server:
- ca.cert.pem (and ca.cert.der) ==> Those are the CA cert files of “FOG Server CA” from above. Both the exact same CA just different formats (PEM and DER). The later (DER) is used by the fog-client installer (probably because reading DER format is easier in C# code I think) while the PEM file is only used if you enable HTTPS on your FOG server. Again, this part is complex and prone to errors - especially if people want to put in their custom CA.
- srvpublic.crt ==> Public certificate signed using the “FOG Server CA”
- .srvprivate.key ==> Private key file matching the certificate above.
I see now that if you rerun the installer it will overwrite your custom certificate files. I’m guessing after upgrading from 1.5.8 to 1.5.9 these were overwritten?
The file srvpublic.crt will be re-generated when running the installer. So yes it’s being overwritten. But the ca.cert.pem is not being re-generated unless you tell the installer (–recreate-ca). Instead the CA certificate is being re-copied from it’s original “store” in
/opt/fog/snapins/ssl/CA/.fogCA.pemand overwrite what you have in/var/www/html/fog/management/other/ca.cert.pem.Do I need to recreate the CA’s with ./installfog.sh --recreate-ca or what else should I do?
I don’t think you should do this!!
-
@sebastian-roth You’re incredible. I really appreciate you taking the time to explain this to me. I’ve been using FOG quite often and even merged it to another subnet and got it up and running again through the help of the forum here and wiki. And yes, re-reading what I stated above I didn’t really have a direct question. My brain was fried and kind of all over the place after researching, apologies there. The reason I was wanting to update this cert was because I thought maybe it was the reason why we cannot upgrade to the newest FOG Client version. We are on 0.11.19 I think? But when trying to install the newer client I get a certificate error. (I can get the specific error once I get back to work tomorrow). Upon deployment, auto-join to the domain stopped working for us so I was hoping upgrading to the newest version might just fix it. From my understanding, once the machine is imaged, the FOG Client does post tasks like auto-joining to the domain?
-
@tlems said in Expired Certificate Help:
The reason I was wanting to update this cert was because I thought maybe it was the reason why we cannot upgrade to the newest FOG Client version. We are on 0.11.19 I think?
Please grab a copy of
C:\fog.logfrom the machine you think has an issue and post that here (upload full log).But when trying to install the newer client I get a certificate error. (I can get the specific error once I get back to work tomorrow).
Yes please take a picture of the error and post that here.
Upon deployment, auto-join to the domain stopped working for us so I was hoping upgrading to the newest version might just fix it. From my understanding, once the machine is imaged, the FOG Client does post tasks like auto-joining to the domain?
That that should be the case if everything was setup correctly. Again I suggest you start looking at the log on the machine as mentioned above and I am sure we’ll figure out why it doesn’t do the join. There are many reasons why this might fail.
-
@sebastian-roth The error states “Unable to install CA Certificate” and just looked at the fog.log and it was there right at the top. The FOG client is still pointing to the old IP address for the FOG Server. If you still want the logs posted, I can.
-
@sebastian-roth I might just change the settings.json to the correct IP address and keep the FOG Client at 0.11.19. We’ll see if that fixes it for us.
-
@tlems said in Expired Certificate Help:
I might just change the settings.json to the correct IP address and keep the FOG Client at 0.11.19. We’ll see if that fixes it for us.
Yes you can manually changing the IP in settings.json. But this will only work if both servers are using the same CA.
The error states “Unable to install CA Certificate” …
Which fog-client (version) did you try?
-
@sebastian-roth I tried installing the 0.11.20 version.
-
@sebastian-roth Also, when we changed the subnet of the FOG server we didn’t create a new Server. I changed the IP values inside our original FOG server and reran the FOG Installer for the IP addresses to be changed throughout. After I ran the installer, I didn’t do anything with the certs inside the FOG server.