Improved Certificate Management

Feature
, ,
1

I follow this advice…

… and request the implementation of an improved Certificates Management. It should guide the user in typical use cases like:

  • requesting a creating a Let’s encrypt certificate for the hole system
  • requesting a creating a Let’s encrypt unique certificate for singele vhosts
  • add certificates for new subdomains of existing domains/vhosts
  • deleting certfificats
  • recreating and installing single certificates in case of incidents
  • integrated backup and restore function directly within this management system
  • export public and private certs esp. for TLSA generation (or implement directly a TLSA-Generator)

There are probably other useful use cases.
Feel free…

Best regards, Marko

3 Likes
2

Hi all,

There should also be a parameter for asking a test certificate so not to reach the 5/7 limit.

Michel-André

3 Likes
3

The improved UI should also offer the possibility to generate TLSA-Records with some options:

  • automatically selection of the domain-related cert.pem
  • option to select protocol and port (or “*”)
  • option to select TTL
  • option for the client to check for a valid certificate chain
  • hash type
  • hash algorithm
4

Given that Certbot issues new certs every 60 days, I’d have to disagree with this–you’d need to update the TLSA record with every new cert. This would only be practical, IMO, if you had programmatic access to your authoritative DNS Host’s records, so that the updates could be made at the same time as the cert renewal.

I mean, I guess it wouldn’t hurt to have the certificates panel give you this information, but it seems like its usefulness would be very limited.

5

You are right.
Unfortunately my DNS provider don’t offer such interface.

Would it be a solution to configure the Nethserver DNS-Sever as slave and enter the essential records there? Then it should be possible to generate / renew TSLA records, right?

Sincerely, Marko

6

You can already do all this things: just add the new names to the existing certificate.

Just a request a new certificate, everything will work out of the box.

There is no a specific UI for this, but you can do in 2 different ways:

Everything is already integrated inside the configuration backup. If you really need to extract a single certificate, you do it by hand since all files are packed in a tar.gz.
Honestly, I do not think this is really need: just request a new certificate … they are free! :smiley:

I agree with @danb35: LE and DANE integration is a little bit tricky.

It’s already there, and it’s used every time you request a certificate: the validation step is done using a test certificate.
See the underlying command for more info: https://docs.nethserver.org/projects/nethserver-devel/en/latest/nethserver-letsencrypt.html#nethserver-letsencrypt

1 Like
7

Hi Giacomo,
well, somehow you get it done. But the user expanse is (sorry) terrible. The UI is not free of interpretation and offers enough possibilities to be misunderstood.
Many use cases require manual intervention…

you do it by hand since all files are packed in a tar.gz.

use the command line:

…or are not well documented.

  • delete a name from the current certificate, then request it again

Especially the use case “explicit certificates for individual vhosts”, is not documented anywhere.
The deletion is hidden in the documentation of the base system (old).

It is not without reason that I needed so much support; and that is why I have been using SSL certificates for years. Initially created and managed manually, then under Plesk. But the UI makes it difficult to transfer know-how because it is not clear what consequences a certain procedure has bow. which procedure has to be practiced to get an expected result.
The feature request does not mean “offer any possibility to manage certificates”, it is about optimization, especially user experience.
For example, I would prefer to have a function on each vhost to create dedicated LE certificates.

Of course, you can also take the standpoint that I was particularly clumsy here. But I don’t really want to put on this shoe.

2 Likes
8

It’s easy enough to do, but it isn’t on the vhost page. Create the vhost, go to Let’s Encrypt, issue a cert for that name. Go back to the vhost page, set the host to use the new cert. Automatically issuing a cert on vhost creation would be better, though it would mean you’d need to have your DNS records published before creating the vhost.

9

Hi Dan, respectfully I disagree. Please read the thread and see how “easy” it was.

Of course, you can also take the standpoint that I was particularly clumsy here.

though it would mean you’d need to have your DNS records published before creating the vhost.

Well, that’s exactly what I did. And that should not be the problem.

Sinceryl, Marko

10

That’s 136 messages in a thread that doesn’t particularly interest me, and in which it’s far from evident why Michel is recommending you manually delete files at the CLI. But for the sake of science, I decided to test it. Here’s what I did:

  • On my DNS host, create a CNAME for a hostname I’ve never used before, pointing to my main Neth server.
  • On Neth, in Cockpit, Web Server settings, create a new vhost. Set its FQDN to the one used above, and leave everything else at defaults.
  • Still in Cockpit, System → Certificates, request a new certificate for the new FQDN. It succeeds.
  • Back to the virtual hosts page, set the new vhost to use the new cert and require SSL.
    (i.e., pretty much exactly what I said above)

Result:

image
image760×354 93.4 KB

1 Like
11

Not sure what you mean here. If you want Neth to automatically request a cert for a vhost when you create the vhost, it’s essential that the DNS records pointing the FQDN(s) in question already be published (the cert could be requested using DNS validation–in which case those records wouldn’t need to be published–but Neth doesn’t do it that way, which is the biggest reason I don’t normally use its built-in cert management tools). But you might not want to do that–the reason that comes most readily to my mind is that you want some time to work on the content of the vhost before you go live with it. And if those DNS records aren’t there, cert issuance fails. So having the system automatically request and apply a cert when you create a vhost may not be as good of an idea as it appears on first glance.

12

Your answer doesn’t address the question. The answer is simple from the CLI: certbot delete --cert-name <blah>. It’d be nice to be able to do it through the GUI, though IMO pretty low-priority.

Sure, all of these things can be accomplished in this way. The problem is that it’s pretty poorly integrated, and the request is that they be better integrated. So, to be clearer:

I’d read this as wanting to push a button to get a single cert for every FQDN the system answers to–whatever was entered as the system name, www.domain, mail.domain, any vhost FQDNs, etc. It should be relatively straightforward; the system already knows all these FQDNs. Why can’t it automate this?

“Add the new names to the existing certificate” doesn’t do this. Again, I’d expect the idea would be that the system request a cert as soon as the vhost is created, and apply it to the vhost, without any further admin intervention. It’s certainly possible to do this manually (see my post just up-topic), but really it ought to be automated.

Neth by design is very wedded to the idea that you’re going to have one cert that’s going to cover everything the system does (e.g., why is LetsEncryptDomains a property of the pki key, as though a server will have only one Let’s Encrypt certificate?). Since the advent of Let’s Encrypt, that’s bad design, IMO.

Getting a cert is well-documented (and trivial). Assigning a cert to a vhost is well-documented (and also trivial). Combining the two, as I’ve shown above, is also trivial, and I’m struggling to see how it isn’t obvious. The ux could be improved, to be sure, but it isn’t like it can’t be done, or like it’s difficult to do.

2 Likes
13

You’re right. Certificate management is designed to ease the configuration for inexperienced users.
Many users doesn’t even know how certificates and LE works: so IMO this is still the best approach for anyone.

Certbot supports dozen of scenario, like DNS verification and wildcards certificates and I’d like to have them exposed, but only very few users will use it. :frowning:

So for now, we have no plan to change current implementation.
But if anyone want try creating a parallel advanced UI (and backend), I will gladly review the code.

1 Like
14

If that’s the case, why not implement this:

?

Surely this would greatly “ease the configuration for inexperienced users.” And even experienced users make typos. Requiring the user to manually type in a list of names that the system already knows just seems redundant.

1 Like
15

@danb35

Hi Dan

This quoted bit would be relatively easy to do, as you mentionned, the system has entries, or at least “knows” about these FQDNs…

The other bit is not as easy to implement: These FQDNs could have / or use different Registrars, DNS Servers etc. Not all of them would be API capable…

Consolidating all this can be a headache for an experienced human, a server system would easily be overwhelmed… :slight_smile:

Besides which, even the lists of FQDN - that the machine “knows about” - can easily contain typos and other potential disruptive errors!

But I fully agree, it would be really nice to have!

My two cents
Andy

16

Not really Neth’s problem, as it doesn’t do anything to the DNS host anyway–it just needs DNS records to be populated pointing the FQDN in question to the Neth server. It would be straightforward enough to check this, but Neth doesn’t do it now anyway, and I don’t know that it would be a required change.

True, though minimizing the number of places such errors could appear still seems like a good thing.

Now, error reporting that doesn’t suck would be nice:
image

17

Because most machines have configured also invalid FQDNs, this will make LE fail.

A simpler approach could be a button like “import all FQDNs” inside this dialog:
Screenshot from 2020-10-26 14-42-48

Then the user must review it before clicking “Request”.

2 Likes
18

Presuming the user could also edit the imported FQDNs, that sounds like a good way to handle it.

2 Likes
19

Importing the FDQN will be limited to only the supported modules…

20

That would cover the bulk of the FQDNs; the “user edit” capability I mentioned would allow for any others.