Certificate error

Antibiotic

johnpoz

@Antibiotic here is walk through I did back in 2019

https://forum.netgate.com/post/831783

Antibiotic

@johnpoz Thanks, this guide work for me as well)))

johnpoz

@Antibiotic glad you got it sorted.. The only bad thing is browsers now complain about long life certs.. I think something like 398 days or something max..

Use to be able to create a cert good for 10 years, and have no worries most likely for the life of the equipment you were using it on.. Now you have to renew it every year or so..

Now that you have a CA your browser trusts you can sign certs with if for all your devices that use a webgui.. So you can get your browser to stop complaining for stuff like switches, printers, other software.. My nas and unifi controllers webguis all use certs signed by my home CA..

Since your using your own CA you can create certs for any domain you want to use, home.arpa for example - or the new .internal that also intended for local use. You can add rfc1918 IPs in you the SAN so that even when you access via IP vs fqdn your browser won't complain.

Sure ACME has been a game changer for Certs.. And is great for something that a browser you do not control will be accessing. I use them for services I expose to the public. But 90 day renew kind of pain, even if can be automated. But you have to use a public domain, which can be problematic to use internally to be honest, you can not add rfc1918 IPs.. For the admin guis of stuff you admin, with your devices - use of your own CA is better option imho..

Antibiotic

@johnpoz said in Certificate error:

complain about long life certs

I use edge and don't have any complains about that 10 years cert, do not see any warnings)))

Gertjan

@Antibiotic said in Certificate error:

I use edge and don't have any complains about that 10 years cert, do not see any warnings))

Microsoft can't publish more then one 'bad news' a day.
The update that will make Edge bark over "10 year certs" is probably already queued.

johnpoz

@Antibiotic all the other browsers have implemented the like 1 year limit.. But seems from a quick google msedge finally got something right ;) If the CA is private, then the limit is not enforced..

oh - another quick google, and wow - seems they all do not enforce limits for private CAs.. Sweet!! When I had moved over to home.arpa and changed my certs I set them to 1 year.. When comes time to renew, back to 10 years for me ;)

See helping people you can learn something new yourself - thanks!!

Antibiotic

@johnpoz Fine)))

johnpoz

@Antibiotic I forked that question to a new thread..

https://forum.netgate.com/topic/187866/ns8250-uart-fcr-is-broken-duirng-boot-os

Antibiotic

@johnpoz Ok. thanks

the other

@johnpoz I read about that every now and then too...
BUT: here it is working with a cert lifetime of 10 years with chromium and firefox (both up to date) without any complaints...

johnpoz

@the-other yeah I saw the headlines about the changes, etc but never really dove into the details.. Just figured it was all certs, and assumed my old certs were just grandfathered in - because I recall reading it was for certs issued after a specific date.

So when I redid mine to move to home.arpa I just made them for 1 year.. What I get for not reading the small print ;)

stephenw10

Mmm, I'm pretty sure it does apply to server certs. We had to change the default values for the gui and openvpn wizrad etc. But the CA cert can still be much longer.

Antibiotic

@johnpoz Hello can me use pfSesne system/patches to apply this patch or its only for pfsesne inside system? I mean over this can implement any pacth to system or only from redmine.pfsense.org?
https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66

Darkk

Create a CA Root with 10 year lifetime. Then create another CA cert and have it signed by CA Root. And finally create your normal certs and have it signed by the previous CA cert. This is how chain of certificates work.

The reason for the chain is part of how you revoke the certs. So for example if you revoke the server cert you just recreate the new server cert and have it signed by previous CA cert which is also signed by CA Root.

Just import your CA root into your browser and trust it. From then on any certs signed by CA root will automatically be trusted.

CA Root << Primary root cert
CA cert << intermediate cert signed by CA Root
CA cert signed by intermediate cert which you use for servers such as HAproxy and webGUI.

You should have three working certs.

Hope this helps.

stephenw10

@Antibiotic said in Certificate error:

@johnpoz Hello can me use pfSesne system/patches to apply this patch or its only for pfsesne inside system? I mean over this can implement any pacth to system or only from redmine.pfsense.org?
https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66

The System patches package only looks for pfSense commits if you try to create a patch by commit ID. You can of course import a diff file or copy/paste the diff in directly. However you can't do it with that patch because it's a compiled driver, that's the source code. You can on;y patch run time scripts in pfSense dircetly.

You should start a new thread for anything that isn't certificate related. It's very difficult to follow your questions when you keep changing topics part way through a thread.

Steve

Antibiotic

@stephenw10 Ok. sorry

stephenw10

No worries.

johnpoz

@Antibiotic for questions that have nothing to do with the original thread, its best to create a new thread.

johnpoz

@stephenw10 I just check, created a cert for 10 years.. Put it on my printer and firefox didn't say a word about it being valid for 10 years.. Signed by my CA that it trusts..

https://source.chromium.org/chromium/chromium/src/+/main:net/docs/certificate_lifetimes.md?q=certificate%20lifetime&ss=chromium&originalUrl=https:%2F%2Fcs.chromium.org%2F

Beginning with Chrome 85, TLS server certificates issued on or after 2020-09-01 00:00:00 UTC will be required to have a validity period of 398 days or less. This 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.