Okay, so I have come to the conclusion that I am unable to update the NTP time server hours because the Unbound DNS resolver is not accessing the pem certificate file. I have some doubts that this is due to a firewall misconfiguration, but I do believe that the CA-bundle certificate file has been somehow altered. Therefore, I would like to ask the respected members and users for some considerations. I know that the issue is associated with the SSL-CTX certificate misconfiguration.
Having said that, the Packfire also does not update. Instead, the system somehow has a synchronizer with a server that refreshes approximately every 12 hours. Does this make any sense to you? I assume that the synchronization event is with an unknown server where the NTP and Packfire update!
Yes, I configured Unbound to make requests to my DNS servers, and this does not affect the remote control, which is enabled and requesting the non-existent bundle.cer certificate. The CA-bundle and CA-trust-bundle exist and have the keys filled in. I have not confirmed nor do I know if the keys are correct and in accordance, or if perhaps some malicious PGP was introduced without my knowledge!
I await some ideas, please. Thank you.
What should I do?
Regards.
The only change made to the Mozilla certificate bundle is that we have removed the TrustCor CA from the bundle. Mozilla has marked this as distrusted but that marking is not able to be used in the IPFire systems so the only way we could follow the Mozilla distrust was to remove that CA from the bundle.
Did a reeboot to take the pictures and noticed the unbound dns server* was not running.
Edit:
*Pardon me not dns server but dns proxy was not running.
sorry is .crt not .cer
Thanks
It looks Im missing a file in the unbound directory unbound_control.pem all other issues were fixed as it was missing the action allow for the Lans ips.
Yes certificates problem here help!
Which files do you have in your ```/etc/unbound/```` directory.
This is what I have
ls -hal /etc/unbound/
total 68K
drwxr-xr-x 3 root root 4.0K Jul 3 19:44 .
drwxr-xr-x 53 root root 4.0K Jul 7 21:35 …
-rw-r–r-- 1 root root 139 Jul 3 19:44 dhcp-leases.conf
-rw-r–r-- 1 root root 604 Jun 27 10:57 forward.conf
-rw-r–r-- 1 root root 3.8K Jun 27 10:57 hosts.conf
-rw-r–r-- 1 root root 13K Jun 12 16:50 icannbundle.pem
drwxr-xr-x 2 root root 4.0K Jun 12 16:50 local.d
-rw-r–r-- 1 root root 3.3K Jun 12 16:50 root.hints
-rw-r–r-- 1 root root 0 Jan 10 2020 safe-search.conf
-rw-r–r-- 1 root root 233 Jun 27 10:57 tuning.conf
-rw-r–r-- 1 root root 1.5K Jun 9 20:49 unbound.conf
-rw-r----- 1 root root 2.4K Mar 6 2017 unbound_control.key
-rw-r----- 1 root root 1.3K Mar 6 2017 unbound_control.pem
-rw-r----- 1 root root 2.4K Mar 6 2017 unbound_server.key
-rw-r----- 1 root root 1.3K Mar 6 2017 unbound_server.pem
Is it just the unbound_control.pem file you are missing or are there more files that are not present?
I believe this certificate set is created when you first install IPFire. If the .pem file is missing then it has been somehow deleted.
If you have a backup file then doing a restore will put that file back in as it is part of the backup set.
You can check this out beforehand by opening the backup file with an archive reader program. Although the backup file has a .ipf extension it is a .tar file.
If the unbound_server.pem file is in your backup then do a restore.
If the file is not in your backup then it must have been deleted earlier or some problem occurred when you did your initial installation.
If the file is not in your backup then you are going to have to do a fresh installation and start over again.
In this case do not restore from the backup otherwise the .pem file will not match with the .key file
@g70p
For important functions, I use IP insted of domain name. Therefore I use for NTP the IPs for requests.
At an startup, not all services are ready and run. Some timing could cause such an matter.
Maybe you try that way and check?
By the way
I often recognized, that the proxy sometimes was not running after an reboot. Clients were not able to communicate with the internet. So I choose save & restart at proxy UI config, to get proxy running.
@bonnietwin I have a reason to haven’t ssh my ipfire, this due to overall SSL and certificates for past months! I will ask you to get along without me ssh’s to ipfire @trash-trash good to hear from you too.
ok so my unbound folder wasn’t either touched or rm what I did few weeks ago was deleting clamav group but since then not being able to contact servers normaly have been keeping me away from reinstaling and chmod the clam av group*. In the unbound directory I have:
dhcp-leases.conf
forward.conf
hosts.conf
icannbundle.pem
local.d
root.hints
tuning.config
unbound.config
@Trash if I set time trough windows it get’s trough port 123 with domain.name. Also in firewall outgoing rules it’s the ip of the domain. I can try to writte the respective ip but tcp udp http and https are alowed to go throught red interface to the red otherwise I wouldn’t be replying too.
Dns providers aren’t blocking access to servers, neither ntp.
*Actually I uninstalled clamav due to not contacting servers normally, wondering where freshclam was getting those updtates!
@trash-trash 195.22.17.7 returns for 1 ipfire pool ntp org but has a portuguese flag, wondering if this is the location block enabled! The flag shoug be from germany I suppose. I see in the connection tracker the ipfire(black) reaching the port and the destination ip. Doesn’t refresh the OS system wich takes me to SSL-CTX. Allowing connections from some other countries just a second…
no, disbled some locations still not updating system time, altough through window time settings in internet time I can see the conection to pool ntp org and all goes to a portuguese location! Is that normal? this pool was 91.209.16.78, portuguese again!
I can’t even read my emails in privacy not understanding why certificates aren’t present. This was what I was pursuing in this windows machine! I know my AV have the ability to change SSL certificates, but I’ve been a little worried about this practice has this could be tampered or poisoned! Well I disabled the https verification and doing SSL verification for sites manually, wasn’t expecting to have the same issue with certificates in ipfire but it looks I’m going the same road again, wondering if any help! Sugested to copy paste from an original to the directory! I have troubles in using mnt. Is ipfire prepared to get a USB? I really wouldn’t want to ssh there.
The FQDN’s can resolve to multiple time servers from the ntp pool which is why you will likely get different IP’s every time you resolve the FQDN. They can also be from anywhere in the world.
If you can add the IP for NTP insted of domain name at IPFire NTP UI for a test?
Else you can choose NTP IP of your ISP.
Germany ? Hetzner ? 1.ipfire.pool.ntp.org 46.4.54.78 DE Hetzner
yes that went rright trough to germany but just the ip the domain name goes to Portugal. @bonnietwin Yes, Iknow it can pick trough difrent clients it’s general. was expecting to go somewherelse tough!
I know you are able to search by your self… And I think you are already using the command line… But to make the way little shorter, I add link to the command line info of Pakfire here:
thnks @trash-trash and @bonnietwin
So, Is it plausible to think that during an update/upgrade of Pakfire from version 174 to version 175, some SSL key details could have become corrupted or the key lookup location changed?
Regards
PS. maybe system settings in ipfire and files didn’t allow the change during upgrade to new SSL’s certificates as I’m aware of mozillas SSL upsets last months
PS2. Wondering if backup and restore will return the issue!?
There have been some people that had some issues in the past when doing upgrades that things got corrupted. That seemed to be related to when upgrades were longer and it looked like nothing was happening with pakfire so the button to start the upgrade was pressed a second time and this caused a problem.
However fixes were made to pakfire a while back to resolve that issue. You now see a clock which tells you that things are still going on and even if you went back to the pakfire screen and tried to start the upgrade again, it now checks if an upgrade is ongoing and will not start another one.
So yes things can go wrong but what might cause it I have no idea about other than maybe some hardware marginality issues - so a memory hiccup or something similar.
I have never experienced a problem during any of my Core Update upgrades so I have no data about this.
All system settings defined in IPFire allow it to do what it needs to do through a Core Update. If they are preventing something in the Update then those settings must have been changed in between somehow.
What Mozilla SSL problems are you referring to?
There could be a risk of that depending on what the root cause of your problem is.
Trust core distrust. Isn’t that related to SSL CA authority? I have so much to do sometimes my quick reading overlaps details. It’s the first link you shared. Actually was found in cell phone apps but the issue is the same bad ssl certificates, bugs, crashing worms, some redirects to sites or install spywear etc. Well once the new ipfire is 176 and will have the new openSSL I’ll be trying that one,ALso I’ll be changing hardware might micro memorie and intel issues have got something to do with it. Unfortunatly my ISP modem is CISCO (clamAV) and they ofcourse are being target as a new decryptor was found that allow inter servers spie Cisco warns of bug that lets attackers break traffic encryption I’ll be off the forum while making the transition since this new hardware is where I’m writting now and need to make the change. I’m still requesting suricata to come with http2 feature enabled once http2 isn’t testing and add PeerBlock as an ipadress block list they are awsome. Ok cheers
Regards
G70P
