Using own CA for certificates within OPNSense . How?

Started by knebb, November 05, 2023, 07:29:28 PM

Previous topic - Next topic
I started quite recently. So I can't tell you if it has a notbefor date^^ but it was created recently.
However, I have seen the posts and recreated the root and intermediate as well as the application certificate and limited it to one year.
So I don't know where the error should be.
I have under organization: none in...... and use .home as topdomain. Can this also lead to errors?

Quote from: fiR3W4LL87 on January 30, 2024, 11:54:10 PM
Do you have 20 years in the Root and intermediate CA or just in the intermediate?
I tried this but get untrusted on ios -.-
I have 20 years in the root and no itermediate. All certs issued by that root are limited to 397 days, of course.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: fiR3W4LL87 on January 31, 2024, 12:09:47 AM
I started quite recently. So I can't tell you if it has a notbefor date^^ but it was created recently.
However, I have seen the posts and recreated the root and intermediate as well as the application certificate and limited it to one year.

I use no intermediate certificate either, so I bet that the intermediate certificates would have to fulfill the requirements as well. So you have to either limit the intermediate CA's validity to 398 days or have its "notBefore" date set to something in the past.

As I already stated, there is no such thing as a creation date - technically, there is only a "notBefore" date. You can see that when you inspect the certificate.

Usually, this is set by the CA scripts to reflect the current date. So you either have to set the date temporarily in the past or modify the scripts used to issue the certificates. In the typical Linux CA wrapper scripts, I use a setting like:


CA="$OPENSSL ca $SSLEAY_CONFIG -startdate 20190630120000Z"

Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

January 31, 2024, 05:37:39 AM #18 Last Edit: January 31, 2024, 07:36:57 AM by Fright
have 10 years offline root -> 6 years intermediate -> 2 years end-point. works just well on iphones with Trusted Root
https://support.apple.com/en-us/103769
https://support.apple.com/en-us/102028

Quote from: meyergru on January 31, 2024, 01:40:27 AM
So you have to either limit the intermediate CA's validity to 398 days or have its "notBefore" date set to something in the past.

As already confirmed the 398 days are _only_ for Server / Client certificates, not for Root or Intermediate Root. Running here with a Root (20y), Intermediate (10y) and Server (398d).

I'm not creating certs with the builtin OPNsense Trust / PKI module but just importing them from outside, I can highly recommend the XCA tool for great flexibility and administration:

https://hohnstaedt.de/xca/



Quote from: fiR3W4LL87 on January 31, 2024, 12:09:47 AM
I have under organization: none in...... and use .home as topdomain. Can this also lead to errors?

For the org, yes, that could be problematic: Use _at least_ a O (Organization), C (Country) and of course CN (Common Name), all others are optional.

The domain name just have to match your DNS, so if you have a CN like: hostname.domainname.tld be sure you _ALWAYS_ create the CN _AND_ a corresponding SAN (with the same domainname) and a valid DNS record.

If it doesn't work, post here the full Certificate Chain in text mode (DON'T POST KEY FILES), like:


openssl x509 -in /path/to/root-ca.crt.pem -noout -text

openssl x509 -in /path/to/root-int.crt.pem -noout -text

openssl x509 -in /path/to/server.crt.pem -noout -text


It now works
I have the certificates signed by the root CA with a lifetime of 825.
Now it also works with domain.home

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

Quote from: pharaoas on February 05, 2024, 10:50:27 PM
Limits that work for apple: CA certificate has a naximum of 825. End Entity certificates 397 days.

As stated multiple times in this topic, this is _NOT_ a restriction for Root and/or Intermediate certificates.

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

One can perfectly import a single private Root CA in iOS (and iPad) devices, using Configuration Profiles or just sending the raw pem Root CA certificate and double click it and activate it in "VPN & Device Management". This is fully functional for decades and there are no specials, so stating "BUT this will _not_ work on IOS devices." is simply wrong.

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

February 07, 2024, 03:55:37 AM #24 Last Edit: February 07, 2024, 04:12:44 AM by netnut
Quote from: pharaoas on February 06, 2024, 06:59:24 PM
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?

Multiple people in this thread confirmed the correct working of private Root CA's with a validity >10 year on Apple devices. Links are posted to "official" Apple docs. A personal anecdote doesn't define X509 standards.

I can't explain why your certificate setup isn't working without having access to the full certificate chain itself. Only in this thread I offered at least twice to paste your certificates for some "four eyes" analytics if you have trouble making certificates work.

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

It's completly clear what you're doing, but that doesn't make it right.

Except for device/user specific certificates & keypairs, you don't import Intermediates and Client/Server certificates, that's something that things like web browsers do, as "last effort" if the PKI setup in use is invalid.

The only thing that's get imported on an Apple (or any other) device is the private Root CA and marked as one of the Trusted Root's, this is on top of the default CA Trust Store shipped by Apple https://support.apple.com/en-us/105116 (Challenge: Try to find a Root CA with a lifetime _less_ than 5 years.).

Looking at the OP, this is all that's needed to validate a certificate chain with, in this case, the certificate from the OPNsense Web GUI. Having a valid certificate chain results in the OP's goal to get rid of the: "being annoyed by the frequent warnings about self-signedd certificates".
An important thing to notice at this stage is the fact that this all "just works" because the OPNsense Web GUI is (correctly (*)) sending the full certificate chain (Server + Intermediate Certificate) to the (Apple) device. This way the (Apple) device can validate the chain starting at the imported private Root CA and next the, over HTTPS _received_, Intermediate and Client/Server Certificate.

(*)
[off topic]
OPNsense is a little bit too generous, it send it's Server, Intermediate _and_ Root Certificate when accessing the Web GUI. The Root CA is needless to send, Trusted Root's are defined in the Trust Store as explained above. The exception might be IPSec, where it sometimes makes sense to send the _full_ chain (including Root CA), but you configure that explicitly.
You waste some bandwidth sending the Root CA, but it can't harm in anyway...
[/off topic]

Now the next thing you're talking about are Client/Server (DNS) and/or End User (Email/SMIME) certificates (and keypairs) on the (Apple) device itself, a bit off topic and not needed for OP, but these are supported too. While you can import the Root CA by it's raw pem file, for these type of certificates & key pairs the most common deployment method is a bundle in PKCS #12 format; Did you use that ? How did you "craft" this file ?