Creating WebGUI Certificate

[johnpoz]

@nollipfsense huh... If you own the domain then you can create a ssl with acme, and use that in haproxy..

But depending on the method you use for acme to work.. Things have to be in play, like dns creating a txt record, or being able to hit stand alone http server via that fqdn.

You have to look into all the ways acme can verify your the owner of the domain, etc.

But if its public domain, that you control then yeah you can get a acme cert.. And you never have to have that public accessible if you don't want.

[jimp]

If the DNS provider for the domain you own supports one of the update methods in the ACME package, you don't need to setup haproxy or any web-based validation. Just use DNS, they don't need public A records. The ACME package will make the necessary TXT record and as soon as LE validates it removes the TXT record.

I use RFC2136 updates for lots of internal lab systems that can't ever be reached by the public.

That said, your private hostname(s) will still appear in LE's public record of certificates they issue, but it's not a significant concern for most people.

See also: https://docs.netgate.com/pfsense/en/latest/packages/acme/index.html

[NollipfSense]

@jimp said in Creating WebGUI Certificate:

If the DNS provider for the domain you own supports one of the update methods in the ACME package, you don't need to setup haproxy or any web-based validation. Just use DNS, they don't need public A records. The ACME package will make the necessary TXT record and as soon as LE validates it removes the TXT record.
I use RFC2136 updates for lots of internal lab systems that can't ever be reached by the public.
That said, your private hostname(s) will still appear in LE's public record of certificates they issue, but it's not a significant concern for most people.

So, since I had owned real domain (myfullname.com) and real SSL certificate for it issued by Namecheap, if I create a subdomain, say phones.myfullname.com through Letsencrypted for an SSL, I could choose DNS-Namecheap or DNSNSupdate to validate it; and, although it would appear in Letsencrypted's public records, if someone plugs the domain name phones.myfullname.com they got from such record into their browser, it would not resolve...correct?

In other words, Letsencrypted doesn't capture the IP the request is coming from as they're only interested in the fact that I owned the TLD and that it can be verified...right?

[netblues]

@nollipfsense

LetsEncrypt doesn't deal with ip's whatsoever.

[Gertjan]

@nollipfsense said in Creating WebGUI Certificate:

In other words, Letsencrypted doesn't capture the IP the request is coming from as they're only interested in the fact that I owned the TLD and that it can be verified...right?

Dono if they log the IP you use when running acme.sh script.
You could be using a VPN while renewing ;)

Everybody can suspect you use Letsenscrypt as you indicate in a public record :

And as jimp already said above, all trusted certificate signer use are using databases where they placed some data about every certificate they created.
Also : For OSCP to work (certificates being expired before the end date by you) some info has to be made public.

Before Letsencrypt existed, it was possible to obtain a certificate 'the old way'. Most often not for free, and you had to communicate a lot of files and proof - most often by snail mail.

Btw : I've some domains with quiet accurate personal and/or enterprise whois info.

@netblues said in Creating WebGUI Certificate:

LetsEncrypt doesn't deal with ip's whatsoever.

It would be nice to put also IP's (RFC1918 !) into the SAN list ....

[johnpoz]

@gertjan said in Creating WebGUI Certificate:

It would be nice to put also IP's (RFC1918 !) into the SAN list ....

yeah I doubt they would ever allow that - but you can for sure do that when you create your own CA and create your own certs.. I have devices local IPs listed as SAN for all the certs I create - this way if have to access via IP if dns is down for some reason, I don't get warnings about the cert, etc..

example here are the sans for my pfsense

There are many advantages to just creating your own certs when they are going to be used just locally. Before the browsers use to balk at how good the certs was good for, you could do it once and never have to worry about them expiring..

Issue with your own CA, is you have to make sure your devices/applications(browsers) are going to trust that CA. This at times might not be possible depending on what is going to be accessing the resource via https.. But for local resources that only you or your devices you manage and can have them trust your CA.. it does have advantages.. Any domain, RFC1918 sans, etc. And if you want to get tricky, you could back date the certs to time before browsers only allowed like 1 year certs.. See my pfsense gui certs is good for 10 years ;)

At some point I will be changing these all out, since I do want to move to home.arpa vs my current local.lan.. Just haven't gotten around to it yet.. At that time unless do some changing of date time on the CA, etc. going to be limited to 1 year certs because most browsers now balk at certs created after specific time that have longer valid time..

[Gertjan]

@johnpoz

I fully agree : for my local devices like pfsense, and Syno, several printers and airco, I don't need Letsencrypt certs.

I'm running several web sites with multiple domains, and a mail server for all these domains thus I 'need' Letensrypt. I was using certbot before, switched to acme.sh afterwards as it is just 'one shell script'. I wanted to understand how the automation of obtaining cert worke, as it was an annual job, en somewhat complicated. Certs are used everywhere these days.
It was a small step from jimp saying : "Letsencrypt for pfSEnse ? : probably not", to "here is the Letensrypt pfsense package". A I had already everything set up on the 'DNS' side, it was a click-and-done for me.

Btw : Your home made certs are valid until 2027.
Mine are

Not after [indefinitely]

[johnpoz]

@gertjan said in Creating WebGUI Certificate:

Not after [indefinitely]

How did you do that?

Yeah I use the acme package for some certs on services I provide to the public, its pretty slick. I ran into some issues with cert being updated via dns and cloudflare - but that was easy corrected by changing the dns sleep setting from default of 120 to 180..

Since that change have had no issues with renew of certs. ACME for sure has many use cases, I just don't see making much sense for my local devices like my printer web gui, or my switches, or my unifi controller.. Some of these are a pain to change or update the cert.. And having to do it every 90 days would be PITA.. There is no way to automate renew of the certs on such devices/applications.

I might be able to automate it on my nas, but why? I am the only one that access the DSM, and if used acme couldn't put in a rfc1918 san, etc. And would need to use a public domain vs just my local one..

While I like the idea of no expiration for certs on your local devices.. When I created them I was like there is no way in hell I would still be using these things 10 years from now.. For sure the hardware would be replaced, and or some change in certs or domain or something that would require me to change within a 10 year period ;) heheh

[Gertjan]

@johnpoz said in Creating WebGUI Certificate:

How did you do that?

Of course I have a date, always 30 to 90 days in the future, for the validity.
With "indefinitely" I meant to say : one less thing to maintain.

[johnpoz]

@gertjan ah ;)

Unless the auto fails for some reason.. And in my previous post I gave some examples of stuff that just can not be automated anyway.. There is no way could automate the cert on my switches or printers for example. While it might be possible on my nas or unifi controller.. 10 years makes sure I don't have to worry about it either ;)

Setting the cert on the unifi controller software is a real PITA.. I really wish they would just enable setting that in the gui, etc. They also need to update their ssh so you could use modern keys and ciphers.. But the AP are running really outdated dropbear..

Hallway-BZ.6.0.12# dropbear -V
Dropbear v2017.75

[noplan]

OK one of these days read think learn improve

Wow Thx guys!

[NollipfSense]

@johnpoz said in Creating WebGUI Certificate:

And if you want to get tricky, you could back date the certs to time before browsers only allowed like 1 year certs.. See my pfsense gui certs is good for 10 years ;)

Very creative here, indeed!

@gertjan said in Creating WebGUI Certificate:

Not after [indefinitely]

Wow, definitely the best!

[NollipfSense]

So, this morning I decided to create a certificate using the certificate manage to make a root CA, then intermediate CA, and the certificate...the browser (Opera) would still not accept it. Wished I had saw John's date trick.

So for the time wasted, I just bought a domain to use specifically for my home-office-lab network and be done with that.

As a suggestion to Netgate, all community pfSense Plus accounts should come with a real certificate for Webgui...let's make it happened.

[netblues]

@nollipfsense said in Creating WebGUI Certificate:

As a suggestion to Netgate, all community pfSense Plus accounts should come with a real certificate for Webgui...let's make it happened.

Nope. Certificates are not something you put to a product so browsers don't complain. Its a tad more complicated.

As for the time wasted, If you didn't import custom root ca to your browser, what do you expect?

[Gertjan]

Hummm.

Here it is : Opera Not Accepting Certificate (solved) with the same players, the same questions, and the answers.

There is even the ancient TLS certificate--can I make a fake CA?.

Today, we're in 2022. Browser can/could 'hard code' the list with trusted CAs. Be aware.

Remember : a certificate will get trusted if and only if the browser has a copy of the original "CA" in it's local storage.

Also, if you visit your pfSense GUI with https://192.168.1.1/ and your certificate has only "mypfsense.local.lan" as it SAN, this will produce an error.

Two choices :
Add the IP in the SAN.
Visit your pfSense using https://mypfsense.local.lan/ - now the certificate matches the certificate, which is why you use a certificate the first place.

Every device you use to visit your pfSense GUI has to have the CA (chain) imported first.

[NollipfSense]

@netblues said in Creating WebGUI Certificate:

As for the time wasted, If you didn't import custom root ca to your browser, what do you expect?

I am using the latest Opera exclusively for pfSense that does not allow the root certificate to be imported...it relied on the MacOS and that also would not import that certificate. This is not my first time dealing with certificates...I am a Mac veteran on the platform close to forty years.

It seems that my waste of time statement appears as a rude remark; however, none intended...I really have a lot to do on my plate and wished I never embarked on the webGUI certificate. I lived with it for several years so far.

[NollipfSense]

@gertjan said in Creating WebGUI Certificate:

Two choices :
Add the IP in the SAN.
Visit your pfSense using https://mypfsense.local.lan/ - now the certificate matches the certificate, which is why you use a certificate the first place.
Every device you use to visit your pfSense GUI has to have the CA (chain) imported first.

I had tried that, first, using both the host/FQDN (nolli.lan) then got the insult that it's not a real FQDN...then, tried the IP only to find Google wanting to resolve it and quickly switch to Duckduckgo which I use exclusively on all devices. I never visited any site using Opera as it's only for pfSense webGUI.
I gave up and registered a domain after that. Not sure why MacOS Keychain would not import the root CA certificate and instead placed the certificates (all three) in login. In fact, the original pfSense webGUI was in login as well.

[johnpoz]

@nollipfsense said in Creating WebGUI Certificate:

atest Opera exclusively for pfSense that does not allow the root certificate to be imported...it relied on the MacOS and that also would not import that certificate.

What are you trying to import... You sure and the hell can import trusted CA.. I don't care what freaking browser or OS your using.. Failure to be able to do that would be the death of that OS or browser.. Nobody would use it that could say who or not they trust or don't trust..

My guess is you were trying to install the cert vs the CA as trusted..

[NollipfSense]

@johnpoz said in Creating WebGUI Certificate:

@nollipfsense said in Creating WebGUI Certificate:

atest Opera exclusively for pfSense that does not allow the root certificate to be imported...it relied on the MacOS and that also would not import that certificate.

What are you trying to import... You sure and the hell can import trusted CA.. I don't care what freaking browser or OS your using.. Failure to be able to do that would be the death of that OS or browser.. Nobody would use it that could say who or not they trust or don't trust..

My guess is you were trying to install the cert vs the CA as trusted..

Below is Opera showing it's up-to-date and below that is a screen shot showing manage certificate (arrow point)...when one clicks on that, on a Mac, it opens Keychain Access...there is no import certificate button on that Opera page. Hope someone with a Mac can replicate; to make sure mine was not installed properly when I drag it to the application folder. Also, if one import the certificate into Keychain, it places it under login for the user and not in the root. I tried several times, even tried dragging it to root...no luck, would not go. Note: the certificates were set to always trust after importing into Keychain.

[johnpoz]

@nollipfsense said in Creating WebGUI Certificate:

the certificates were set to always trust after importing into Keychain.

The CA cert.. wasn't this all gone over back in 2019

https://forum.netgate.com/topic/144141/opera-not-accepting-certificate-solved