Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - pharaoas

#1
Hi netnut,

Than simply explain to me, why apple mac os will not trust the keychain when the root CA certificate has a longer lifetime than 825? And when I do the exact same certificate with 825 days or less it works?

Second:
Perhaps I'm not clear enough on IOS:
You can import a root CA certificate to IOS as you (and myself) explained. But when you have an Intermediate Certificate derived from that root certificate and than have an end entity certificate derived from the intermediate certificate this end entitiy certificate is not trusted. Root CA Cert and Intermediate CA Certificate are imported as profile. (And the Intermediate ca certificate is also not shown in general info so you could trust it manually as you can do with the root certificate). All three certificates are created with OPNsense following the OPNsense documentation.

best regards
#2
Quote from: meyergru on January 31, 2024, 12:03:17 AM
I do not know for sure, but I think the restriction for certificate duration apply for the whole chain. Are all your certificates either with a validity of less than 398 days or have a notBefore date < September 1, 2020 00:00 GMT/UTC?
Limits that work for apple: CA certificate has a naximum of 825. End Entity certificates 397 days.
You can use Root CA, Intermediate CA, End entity on a mac by manually trust the Root CA (in Keychain management). BUT this will _not_ work on IOS devices. Here you only can trust a Root CA (Settings->geberal->info) and than use directly derived end entity certificates. (Tested with Sonoma and IOS 15)

I suggest to use the CN as a descriptive name, but put the fqdn in an alternative subjact name. when you are using fixed IP-Adresses for your servers additionally put the IP also as a subject alternative name.

best regards
#3
Hi community,

I had the same trouble that the System->Firmware->Status (and Update) freezes very long or forever as described in this thread.

An earlier post by franco ,,Looks like DNS issues, no upstreams defined in Unbound and/or System-General" brings me to the following idea:

,,I'm using AdGuardHome" for DNS filtering and use Unbound as Uplink DNS. This DNS config works very well (and fast) in my Network (LAN). So, perhaps the problem is in the DNS ,,routing" of the OPNsense itself???
I investigasted a little bit and found a switch at: System->Settings->General named ,,Do not use local DNS-Service as Nameservice" with an explanation, that when not switched on (negative logik!) a DNS service on the loopback device is used.

AdGuard listens on Port 53 but not on the Loopback interface (127.0.01). Unbound listen (i guess) on all interfaces (and so including loopback) by default, but I changed the port to 5353 to avoid conflict with AdGuardHome.
At the end, there is no DNS listenting on port 53 for the loopback device.

These asumptions would explain the behaviour.

I switched off the switch ,,Do not use local DNS-Service as Nameservice". Following the description of the switch this will force OPNsense not to use a DNS on the Loopback interface.
So, the ,,normal" configured way (as in my LAN) is used.

And - This works!!!

Firmware status and Firmware Update is running fast! I do not see any drawbacks of that solution.

I'm using the german frontend of OPNsense and translated back to english for this post. So, probably the switch is named a little bit different, but I hope you can find the setting and please correct me with the wording.

I hope you can follow my explanation and potentially helps others to fix their problems.

best regards