Creating WebGUI Certificate

[NollipfSense]

So, I am creating certificate for webgui as a preliminary to creating another production one for a PBX server. I have been following Jimp's video using DNS-NSupdate method to evaluate the certificate for a domain that will only be used internally and would never resolve externally just like the plan for the PBX server's domain. I understand that using this method would allow the local pfSense's DNS server to resolve the name. Were I am stuck is where did JimP get the algorithm key or how he generated one? Here's the screen shot from the video: https://www.youtube.com/watch?v=h7Rlru3agdA

Can I generate one on my Mac or pfSense CLI? Then, do I need to configure DNS pre here: https://docs.netgate.com/pfsense/en/latest/services/dyndns/rfc2136.html

Could not find a date for relevance on the above.

[NollipfSense]

Okay, I figured out how to generate a md5 key on MacOS; however, why am I getting this error for a fictitious domain that there wont be an external source wanting to resolve its name...this is only for internal use to be resolve by internal DNS. When I tried DNS-manual, that would not renewed automatically, what am I missing? Is Letsencrypt creating a REAL domain?

Nollininecer
Renewing certificate
account: Nollinine
server: letsencrypt-production-2

/usr/local/pkg/acme/acme.sh --issue --domain 'nollinin.xxx’ --dns 'dns_nsupdate' --home '/tmp/acme/Nollininecer/' --accountconf '/tmp/acme/Nollininecer/accountconf.conf' --force --reloadCmd '/tmp/acme/Nollininecer/reloadcmd.sh' --log-level 3 --log '/tmp/acme/Nollininecer/acme_issuecert.log'
Array
(
[path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
[PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
[NSUPDATE_SERVER] => /tmp/acme/Nollininecer/nollinin.xxxnsupdate
[NSUPDATE_KEYNAME] =>
[NSUPDATE_KEYALGO] => 157
[NSUPDATE_KEY] => /tmp/acme/Nollininecer/nollinin.xxxnsupdate
[NSUPDATE_ZONE] =>
)
[Tue Feb 8 16:10:59 CST 2022] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Tue Feb 8 16:10:59 CST 2022] Single domain='nollinine.net'
[Tue Feb 8 16:10:59 CST 2022] Getting domain auth token for each domain
[Tue Feb 8 16:11:01 CST 2022] Getting webroot for domain='nollinin.xxx’
[Tue Feb 8 16:11:01 CST 2022] Adding txt value: 6Ub8PxXmEgkX-eLki3pNELDI9kUasIvJuzaijn3tu-g for domain: _acme-challenge.nollinin.xxx
[Tue Feb 8 16:11:01 CST 2022] adding _acme-challenge.nollinin.xxx. 60 in txt "6Ub8PxXmEgkX-eLki3pNELDI9kUasIvJuzaijn3tu-g"
couldn't get address for 'nollinine.xxx’: not found
syntax error
[Tue Feb 8 16:11:01 CST 2022] error updating domain
[Tue Feb 8 16:11:01 CST 2022] Error add txt for domain:_acme-challenge.nollinin.xxx
[Tue Feb 8 16:11:01 CST 2022] Please check log file for more details: /tmp/acme/Nollininecer/acme_issuecert.log

[NollipfSense]

I looked through the log: /tmp/acme/Nollininecert/acme_issuecert.log and it seems first that the certificate was issued. Maybe that was when I used DNS Manual but that doesn't allow automatic update. So I changed the DNSNSupdate the certificate won't renew.

[netblues]

@nollipfsense So you are trying to create a letsencrypt signed interface certificate for a domain that does not exist on the Internet?

This will never ever happen.
as the log complains... couldn't get address for 'nollinine.xxx’: not found

[Gertjan]

With @netblues here.

@nollipfsense said in Creating WebGUI Certificate:

Is Letsencrypt creating a REAL domain?

Letsencrypt is free.
Read the first paragraph.
Add to that : Domain names 'that you control' are not free.
As you do not control facebook.com, microsoft.com or example.com ;)

Letsencrypt, while probing, will resolve "example.com" on their side.
Both (or more) domain name servers of your domain should be synced and give the same answer for a TXT record in the "_acme-challenge" sub domain.

That's what the "DNS-NSupdate method" is : It instructs the master DNS of your domain (ns1.example.com) to add a TXT record in subdomain, with a given value.
When restarting the renewal or initial creation, Letsencrypt will give a random text value. Yours was 6Ub8PxXmEgkX-eLki3pNELDI9kUasIvJuzaijn3tu-g. It will be another value the next time.
Up to your local method to stash it into the "ns1" master DNS domain server.
The master domain server will signal all the slaves (at least one) domain name servers.
These slaves will, whenever they want, will sync up with the master. This can be "immediately" or 10 minutes later - or even later. If the authoritative master and slave domain name servers are not yours, they might have 'more to do', so these sync 'X-FER) command will get queued for later execution.
Now you know why this settings exists :

So, yes, Letsencrypt certificates are are free.
Domain names are not - if you want a certificate that all browser trust, it will be anything from a couple of €/$ per year. Check here : most expensive tld.
example.com is NOT available right now - and robably won't be as long as the Internet exists ;)
When picking a registrar, as you can't get domain names at Wallmarts (can you ?) see what "Letsencrypt" update method they propose. The NSupdate is, IMHO, the best. Others use dedicated APIs. Here is the list.

[johnpoz]

@nollipfsense if you just want a cert that your browser trusts just create your own CA and create your own certs your browser trusts

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

If you want browsers outside your control and or possible other devices and you want a public trusted cert, say from acme - then the domain needs to be public domain.

The pfsense webgui should really only ever accessed by admins, etc. So your own trusted certs is better option if you ask me. you can use whatever domain you want, you can use rfc1918 address in the SAN, etc..

[NollipfSense]

@netblues said in Creating WebGUI Certificate:

@nollipfsense So you are trying to create a letsencrypt signed interface certificate for a domain that does not exist on the Internet?
This will never ever happen.

@gertjan said in Creating WebGUI Certificate:

Letsencrypt is free.
Read the first paragraph.
Add to that : Domain names 'that you control' are not free.

I must have misunderstood it seems. I thought that Letsencrypt allows one to create fictitious domain(s) that would never face the public, and gives one an SSL certificate for that domain. And, I am saying this having legally own several domains myself. So I was very confused.

In Jimp's video, it seems that he had created a fictitious domain and I followed the steps...I just didn't create what appears a subdomain as he did.

@gertjan said in Creating WebGUI Certificate:

That's what the "DNS-NSupdate method" is : It instructs the master DNS of your domain (ns1.example.com) to add a TXT record in subdomain, with a given value.
When restarting the renewal or initial creation, Letsencrypt will give a random text value. Yours was 6Ub8PxXmEgkX-eLki3pNELDI9kUasIvJuzaijn3tu-g. It will be another value the next time.

So, based on what you said here, Jimp actually owned the domain he used. Wished that was made clear.

I literally spent the whole day monkeying with this, replaying the video and watching each steps as well as others on YouTube. I was wondering why some people were using Cloudflare DNS and wished I have asked earlier.

So, pfSense DNS server doesn't actually resolve any fictitious domain only used internally and would never face the public...correct?

[johnpoz]

@nollipfsense said in Creating WebGUI Certificate:

pfSense DNS server doesn't actually resolve any fictitious domain only used internally and would never face the public...correct?

No pfsense can respond to a query for any domain you want, be it something it resolved from the public or something you just host locally. My domain I use internally is local.lan - this is not a valid public domain, could never resolve since .lan is not a valid public tld.

But acme can only hand out ssl for public facing domains. Something that anyone on the public could resolve.

Certs for whatever domain you want can just be created with CA you create in pfsense.

[NollipfSense]

@johnpoz said in Creating WebGUI Certificate:

@nollipfsense if you just want a cert that your browser trusts just create your own CA and create your own certs your browser trusts

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

If you want browsers outside your control and or possible other devices and you want a public trusted cert, say from acme - then the domain needs to be public domain.

The pfsense webgui should really only ever accessed by admins, etc. So your own trusted certs is better option if you ask me. you can use whatever domain you want, you can use rfc1918 address in the SAN, etc..

John, I am now understanding how it all work based on the two previous responses...thanks

[NollipfSense]

@johnpoz said in Creating WebGUI Certificate:

My domain I use internally is local.lan - this is not a valid public domain, could never resolve since .lan is not a valid public tld.
But acme can only hand out ssl for public facing domains. Something that anyone on the public could resolve.

I had wondered why when I first tried "nollinine.lan' through the Letsencrypt I got the same insult. Thanks, John for clearing up my misunderstanding.

[NollipfSense]

@johnpoz So, If I want to use a domain that I own in order to get an SSL certificate for my FreePBX that would never face the public in the sense that it's for HAproxy to use to reverse proxy calls to my PBX server, wouldn't that get resolve to my FreePBX?

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