What’s the point of creation of CSR ?
Why do I need to fill out Address for this stuff ? Who cares about it ?
Why do I need to configure 2 things (CSR and Create ACME cert request) in order to create a certificate ?
With certbot all I have to do is certbot certonly -d site.example.com and I get a certificate
With other web UIs like Opnsense - I just add a new certificate and click request button - super simple.
Agreed. Not to mention this completely nonsensical default (still the case as of 25.04-BETA):
Edit: See also:
https://ixsystems.atlassian.net/browse/NAS-118022
https://ixsystems.atlassian.net/browse/NAS-118021
Unfortunately, neither of those tickets are accessible to the public.
Here’s one of mine, addressing the 10 days issue, in case it’s available to the public:
https://ixsystems.atlassian.net/jira/software/c/projects/NAS/issues/NAS-117031
TLDR, it was not accepted.
Both opened in Sept '22; one was “change the idiotic nonsensical 10-day default”; the other was pretty much what OP is saying. Both closed in Jul '24 with “make a feature request on the forum instead.”
My enthusiasm for helping iX find and fix obviously-wrong design decisions (which both of these are) is limited.
A 10-day SSL renewal default can likely be traced back to the desire to harden the NAS - like changing the default admin name, etc. Short intervals potentially make compromised certificates less valuable, no?
But they also only make sense if one has a business account with a certificate authority (CA) or runs a CA in-house.
IIRC, ZeroSSL and others default to 90 days to keep server traffic reasonable and likely would frown on very short renewal intervals. But that addresses a different crowd than the merry band that runs TrueNAS at home.
Nope, the cert (from Let’s Encrypt, the only ACME CA natively supported) is still valid for 90 days. They do now issue 6-day certs, but those require more advanced support than TrueNAS yet has.
The problem is that LE expects you’ll renew your cert 30 days before it expires. If you get to 20 days before expiration, they’ll send you a warning (until they stop sending emails entirely, which they will soon).
That’s the TrueNAS tax.
Traditionally, TrueNAS has exposed a lot of functionality at the GUI and CLI level that other consumer/prosumer-oriented systems did not. But making it a friendly or easy process did not appear to be a priority. So from my peanut-gallery POV, the SSL suite for the GUI has been a work in progress for years now.
@Dan came up with a brilliant set of scripts way back in FreeNAS days to allow mortals to add and renew SSLs with relative ease. Since then, iXsystems has marginally increased the number of GUI-enabled CA providers from 1 to 3. It would be nice if someone at iXsystems could sit down to add more providers.
Oh, you mean that spaghetti code?
So that is a easy-fix-bug that iXsystems has known about for years but which no-one there is motivated to fix. That is disappointing.
Fixing the process might not be. I can understand wanting to keep a consistent process to get a cert–create a CSR[1], and then get that CSR signed. So as much as I agree with OP that the process is needlessly complicated, I can almost understand why iX might not want to change it (though I’d still advocate for their doing so).
But the 10-day renewal time is just a silly default and completely ignores all extant documentation on how to use Let’s Encrypt. It would likely be a one-line code fix. But it’s been there since at least 22.02, and iX haven’t yet shown any interest in fixing it.
The (or “a”) nice thing about my script is that it lets you bypass all the GUI nonsense completely.
Edit: you can achieve a similar result using the truenas_ws deploy script that ships with acme.sh. In my completely-unbiased opinion, mine is a lot easier to follow; being written in Python lets it deal with the structures used by the TrueNAS API much more easily. But there’s at least one other option out there.
though the fact that it’s mandatory to populate fields that won’t appear in a DV cert, such as Let’s Encrypt issues, is more than a little frustrating ↩︎
Yes, that spaghetti code, which worked just fine for me and other folk looking for a reliable way to secure their FreeNAS/TrueNAS GUI while doing their best to break it. 
That’s the benefit of allowing dabblers like me to beta-test the many ways in which I could break something or other, which in turn allowed the creation of a pretty comprehensive user guide.
@dan is extremely responsive re: improvement suggestions and kind re: explaining why what is going on where.
Forgive me, I’m not a developer. Can you point to this in the User Guide…?
What is the max its allowing for the “renew days”?
Is that Ok, but just default it too low?
(i’d like to review the documentation).
There is not a Feature Request for a change. I do recommend using that. The voting system lets us underderstand how many users are potentially impacted.
FYI… there is some work being done to automate SSL certificates more easily. Its not in Fangtooth, but we’ll document when we think we have a real plan and schedule.
It’s too low, should be at least 30days to conform Let’s Encrypt recommendations
I’m afraid I can’t; this option appears to be undocumented. In fact, the entire process of requesting an ACME cert from a CSR appears to be undocumented. I’d expect it to be on this page:
…since it’s done by clicking the wrench to the right of a CSR:
…but there’s nothing I can see at that page explaining how to actually get the cert.
This setting controls when (i.e., how many days before expiration) TrueNAS will attempt to renew the cert. Let’s Encrypt, by far the most popular ACME CA (and the only one TrueNAS supports), recommends renewing at 1/3 life remaining. Since their certs are (by default[1]) valid for 90 days, that means you should begin attempting to renew when 30 days’ validity remain. This is documented in their integration guide, which I linked in the feature request I filed in 2022.
No idea; the UI doesn’t say. It lets me enter 99 without complaint though.
I don’t know what the max is, or even if there is one, so I can’t say whether it’s too low (though I doubt it), but the default definitely is.
There were at least two, three years ago, linked up-thread (and a third, also linked up-thread, that would have been more in-line with OP’s request, but admittedly would have been a bigger change to the code). Nothing was done with them. When you ignore objectively-obvious fixes[2] that would take about one line of code, it doesn’t exactly motivate us to start over in the new system.
This is encouraging, I guess–better late than never and all that. There are really only two pieces of information the system should need in order to obtain a cert from Let’s Encrypt:
There’s absolutely no reason to create a CSR first. There’s even less reason to require information be included in that CSR that’s just going to be discarded by the CA anyway–country, state, org, locality, and email will be ignored by the CA and stripped from the issued cert (because Let’s Encrypt can’t validate any of them). There’s no reason, really, to even have the cert options–I guess expose RSA vs. ECC and key length, but the rest is all needless complication. And even that can probably be hidden behind an “advanced settings” button.
They’re introducing an option for 6-day certs, but the default remains at 90 days ↩︎
The default in the product is objectively wrong. @neofusion and I both linked you to the docs explaining this, and why the correct default is what it is, in 2022. And there they sat until late last year, when Kris closed them without action. ↩︎
Lets start with this as a documentation bug. (I’ve created one)
We assessed this as a “feature Request” since it was not breaking systems. The fact that is hasn’t been posted as a request is an indication of its Community priority. However, we do view the simplification fo certificates as a priority.
I’m not disagreeing that you are right .
…or an indication that we’ve given up. You’ve had this request since 2022. The default is objectively wrong. It (presumably) would be a trivial fix.[1] But it’s left open without action until late last year, when we’re told to start over. Nope.
And yes, it’s also trivial to avoid the problem, if you know before you create the cert; you can’t change this once the cert is created. ↩︎
To be fair, I had a look through my “Closed - Not Accepted” suggestions over in Jira and after lying fallow in that state for 2 years, @kris added a note to each that I could resubmit those suggestions in the new forum under feature requests.
I know it’s frustrating to have to resubmit the same info multiple times, even when the fix is likely simpler to implement than the time it took the dev to simply stamp the “Closed - Not Accepted” banner across your suggestion. At the same time, it likely would be helpful if more users can give a voice to feature requests than when they had to log in separately into the Jira system.
My suggestions / feature requests would likely take more time, gobble up more resources than a simple find and replace of the default certificate lifetime, whose current number appears to be entirely arbitrary and at odds with the wishes of the SSL cert provider that iXsystems uses by default.
Useful to know. Its where I would like documentation fixed as a starter.
