Using own CA for certificates within OPNSense . How?

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

Previous topic - Next topic
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:

  • 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...
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

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.

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.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

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.

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

November 06, 2023, 11:21:17 AM #7 Last Edit: November 06, 2023, 11:23:27 AM by meyergru
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?
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

November 06, 2023, 11:24:19 AM #8 Last Edit: November 06, 2023, 11:34:23 AM by Patrick M. Hausen
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.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

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.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Different market actors implemented this at different times, all dating back to the CAB Browser Forum initiative to further reduce certificate lifetimes in 2017.

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.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

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
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

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?
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+