Hi,
being annoyed by the frequent warnings about self-signedd certificates I decided to create my own CA and certificates.
So I followed the documentation (https://docs.opnsense.org/manual/how-tos/self-signed-chain.html):
- Created a CA (self-signed)
- Created an intermediate CA (signed by above CA)
- Created a server certificate with the FQDN of this OPNSense
- Downloaded the CA and Intermediate keys (not the private ones)
- Imported both keys (CA and intermediate CA) into the key management of my MacBook
- Marked both (CA and intermediate) as fully trusted
- Switched the wegui certificate from my OPNSense to the certificated I created above.
- Accessed the webGUI
Unfortunately I am still getting the "untrusted" warnings. I can examine the certificate and it is the one I generated about. So OPNSense seems to present the correct one. But why does my MAC complain?
Firefox still shows same warning and Safarie tells me "Certificate does not comply the defaults".
:(
Anyone having an idea?
Thanks!
/KNEBB
Because your self-signed certs are not trusted by your Mac/Browser? Get a Letsencrypt or import into your Mac...
Quote from: chemlud on November 05, 2023, 07:33:00 PM
Because your self-signed certs are not trusted by your Mac/Browser? Get a Letsencrypt or import into your Mac...
I did:
Quote
Imported both keys into the key management of my MacBook
Marked both (CA and intermediate) as fully trusted
Ok, might not have been as clear as I thought. I will modify my post to make it clear.
Hi,
I did some search on the warning Safari gives and found thios topic (https://security.stackexchange.com/questions/262683/ssl-certificate-not-standards-compliance-in-safari).
So it looks like there has been some misconfiguration in the names of the server certificates which will bring this warning.
Herre I am now unsure. What should I use in my certificate?
So I have:
Subject: C = DE, ST = XX, L = XXXXX, O = XXXXXX, emailAddress = admin@domain.zeroed, CN = router.domain.zeroed
[...]
X509v3 Subject Alternative Name:
URI:https://router.domain.zeroed
Might be the X509v3 SAN is wrong? But I used the same which is showed in the documentation. What value should I use?
Anyone some further ideas?
The CN needs to be the FQDN of your NAS. Is that really router.domain.zeroed?
Additionally you need an SAN of type DNS that also reads <FQDN of your NAS> - or "router.domain.zeroed", if that is really the correct one. Which I doubt.
Quote from: knebb on November 05, 2023, 09:04:56 PM
Anyone some further ideas?
A few things:
Quote
Imported both keys (CA and intermediate CA) into the key management of my MacBook
Not the source of your problem, but just import the Root CA cert, all others (Intermediate and Server/Client) will be trusted.
Quote
X509v3 Subject Alternative Name:
URI:https://router.domain.zeroed
SAN names are type DNS (or IP, but don't use that) and don't need a scheme (https), just the fqdn. It depends on your crypto library, but it's good practice to _always_ use a CN and a matching SAN entry.
Can you post your full chain, ie all three certs (Root, Int, Server, don't paste your key!!!). Something like:
openssl x509 -in /path/to/cert -text -noout
I figured it out meanwhile.
Indeed this was not an issue of OPNSense but MacOS instead.
Since 2020 Apple does not allow server certificates to have a validity of more than 398 days. See here (https://support.apple.com/en-us/102028).
So I created another one with 397 days and as SAN "DNS=router.domain.zeroed"
Now it is working like a champ.
Thanks for your input!
/KNEBB
I saw this too late, but there is another interesting drift to that problem (and not only Apple has it). Read closely:
"TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days."
I changed my own CA script to issue all certificates with "from" dates set to 01.08.2020 instead of "now". The CA validity lifetime starts at an even earlier date, of course. That way, I can issue long-lived internal certificates without a problem.
Oh, I just see that this is my 666th post. Coincidence?
Tricksy hobbitses ...! Thanks for that idea.
But in that document:
https://support.apple.com/en-us/102028
it also reads:
QuoteThis change will not affect certificates issued from user-added or administrator-added Root CAs.
Similarly Google:
https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/certificate_lifetimes.md
QuoteThis will only apply to TLS server certificates from CAs that are trusted in a default installation of Google Chrome, commonly known as "publicly trusted CAs", and will not apply to locally-operated CAs that have been manually configured.
So I wonder if I could have issued longer lived certificates with my local CA all along. Need to do some tests.
Seems like the docs don't tell all of the truth ;) Doesn't work. So I'll create a back dated CA later after work, I guess.
Different market actors implemented this at different times, all dating back to the CAB Browser Forum initiative to further reduce certificate lifetimes in 2017 (https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/).
Back then, these rules were rather informal. Matter-of-fact, how could you even know "when a certificate was issued"? "notBefore" is just a wild guess, as you now know. Also, the differentiation between "built-in" vs. "local" CAs is kind of synthetic. It has been implemented in Chrome and derivatives only a short while ago (I can see that my own certificates are trusted, but not from a "built-in" CA in Firefox upon inspection).
Google's specification is the most formally complete to date, however, implementation seems to be yet another thing (tm).
Rest assured, there will be changes coming in the near future that force us to re-issue our CA certificates again. Last time for me was 2020 - I don't even remember which obscure flag was missing / too much. I got notified of it ahead of time because I administered a PSD2 QWAC then whose CA certificate had to be renewed as well.
Hello together
Wanted to ask if anyone has managed to successfully integrate the certificates under Apple as Trusted?
Somehow I find it difficult to achieve this.
I am running this and it works completely painless apart from the burden of renewing all certificates every year.
I created a CA in OPNsense with a lifetime of 20 years, downloaded the CA certificate and then simply double clicked it on the Mac and marked it as trusted. See screenshot.
"Immer vertrauen" == "trust always".
HTH,
Patrick
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 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?
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.
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"
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
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 ?