Nextcloud letsencrypt certificate

switching the default cert didnt really change much. dunno. what i did for the time being is adding those two missing sslCert path entries to zz_nextcloud.conf. which works. the thing about requesting a new proper / valid cert for domain.org and next.domain.org is that the root domain is my website on my providers server. the sub domain is pointing to NS. which probably means that thing wont work for me?
im fine with my current solution even tough it seems messy and eventually would like to have a no terminal messing around solution.
thanks for your patience :slight_smile:

Don’t edit zz_nextcloud.conf directly, the file is templated so your changes will be overwritten.
To apply the config and reset zz_nextcloud.conf file run following on terminal:

signal-event nethserver-nextcloud-update

Just request a letsencrypt cert only for your subdomain pointing to your NS and set it as default.
Nextcloud should now use the cert and be reachable via https://next.domain.org/nextcloud

There should be no terminal action needed for running Nextcloud with LE cert.

…which really is a design problem, and I wouldn’t expect to be that difficult to fix, but they don’t seem to see any reason to want to reduce the number of names on a cert. Kind of unfortunate.

Why? It’s simple and easy to use which is a Neth goal.

i kinda changed my mind regarding the cert count. i was able to solve all “must haves” on my todo list over the past two days. which is awesome :slight_smile: !! but lets me want to install the only nice to have thing on my list which is streaming music to the office/phone.
so basically i want two sub domain certs. one for nextcloud(cert already issued) and another for funkwhale (app and cert not yet installed). next and amp.domain.org. my knowledge is so limited when it comes to those things that it might be better to do this dns ip-domain linking through another service to make the NS interface happy?

Just add amp.domain.org to the LE certificate request when you installed funkwhale and it should work.

Until you need to change the cert. Then you need to issue a new cert (which is inherent in the nature of certs), and manually enter each and every FQDN that needs to be on the cert, letter-perfect, every time. Want to make it “simple and easy to use”? Then, when you enter a virtual host name for Nextcloud:

  • Scan the default cert to see if that name is already there
  • If it isn’t,
    • Parse the existing names on the cert
    • Request a new cert for those names + the Nextcloud name
    • Set that new cert as the default cert
    • Possibly delete the old default cert

Or, better yet:

  • See if there’s an existing cert that covers the virtualhost name (bonus points for parsing wildcard certs)
  • If there’s only one such cert, use it for the new virtualhost
  • If there’s more than one such cert, let the user choose which one to use
  • If there’s no such cert, request one in the background and assign it to that virtual host

Advantage of this over the last is that it doesn’t restrict its check to the default cert, but checks any certs the system’s aware of. If there isn’t one, the new cert covers only the FQDN of the new virtual host. Both of these, of course, would take a fair bit of coding to accomplish (at least as best I can figure). As a simpler-to-code alternative, just let the user pick a cert for the virtual host–that way, they can get a dedicated cert just for that FQDN if they like.

I get the attraction of the multi-SAN default cert–specify one cert one place in the Apache (or whatever) configuration, and you’re good to go. But there are problems:

  • It’s awkward to maintain
    • Despite a concerted effort to assign individual certs to individual services, my default cert still has 18 FQDNs on it
    • If I want to add or remove a FQDN, I need to manually re-type each of those 18 FQDNs (plus any new ones, minus any to remove)
      • This is based on the old server-manager; I’m not sure if the process is different with Cockpit
    • And if I make a typo in doing that, the whole process fails
  • The more SANs on the cert, the larger it is. This (marginally) increases network traffic and TLS handshake time
  • There are privacy concerns. If, for example, you host websites for customers, you may not want client1 (or its customers) to know that you also host client2.
1 Like

@danb35

Hi Dan

I’m using the old Dashboard at home (And for a number of my clients) to manage LetsEncrypt.

Whenever I need to change anything, I just call up LetsEncrypt (Request LetsEncrypt) and all SSL Domains are there. Add a line or remove a line. I do not need to type in the whole list.

Bildschirmfoto 2020-10-01 um 13.47.28

I don’t really see what’s awkward to maintain about this. If I had to maintain a seperate list, which I would need to copy & paste each time, I’d also think of it as a PITA, but as long as the list in NethServer is intact, it’s OK for me.

I don’t quite have 18 FQDNs on the list, but mine is also fairly full…

My 2 cents
Andy

Interesting, it doesn’t behave that way for me:
Screen Shot 2020-10-01 at 7.49.30 AM

It doesn’t even have the admin email, much less any of the other FQDNs on the cert.

If it did that with me, as your’s is doing, I’d be a bit grunty… :slight_smile:

It does for me (so far) on all NethServers… :slight_smile:

That’s 32 NethServers at the moment…

I only have one with a SSL Cert problem, but that has to do with Apache http not running correctly at one client.

My 2 cents
Andy

@danb35

If you fire up a quick and dirty VM to test, does it react as mine or as yours when you try LetsEncrypt?

You may need to temporarily redirect http from your firewall to test…

It should work with cockpit too:

Please check certificate config:

config show pki

OK, I’ll concede that (some of) the awkwardness of cert management is down to an anomaly of my configuration. I think the remaining points still stand.

I think only this point is left (correct me if I’m wrong) but it’s already possible to use different certs for custom virtualhosts.

finally had the nerve to set the one cert as default and all is cool now. so the address is https://next.domain.org/nexcloud. all my devices are set up for an address without the /nextcloud. is there a easy way to redirect that url to https://next.domain.org ? thanks

@tmp501

Hi

It’s safer and more reliable if you erase the old “server” and create a new connection, especially on your mobile devices… (Also on PCs, Macs…)

My 2 cents
Andy

yes thanks. just did that. all good.

1 Like

hey people,

i got a new cert issue. apparently my two certs did not get renewed and expired today (no email). requesting a new one threw me an error. got frustrated and removed the neth-letsencrypt rpm, the files belonging to the two domains under /etc/letsencrypt - reinstalled neth-letsencrypt - reboot and same error. the dns/domain/ip entries are correct - they worked up untill today. any ideas?
ps.: i upgraded to the latest release after the last reboot.

just saw that the http service is not running…

dns.service_action_error
The following command has failed:
`system-services/update`
Unfortunately we couldn't catch the exact error. If you want to help, please click on the button below to copy the failed command to the clipboard, paste it into the Terminal and submit command output to the developers.

http is up again. requesting a new cert still throws the same error

   Domain: funk.domain.org
Type:   connection
Detail: Fetching http://funk.domain.org/.well-known/acme-challenge/6J8rvDQ4YpLG9IITgDx5d5QTyB_qNDZoJ8hq3UOe9xY: Connection refused

Domain: next.domain.org
Type:   connection
Detail: Fetching http://next.domain.org/.well-known/acme-challenge/4gxyXW5b861TFdH27cRaF0Tq_AkwisO8YDFa7jKYpCU: Connection refused

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.
2021-01-19 18:05:14,100:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 91, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, best_effort)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 180, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
AuthorizationError: Some challenges have failed.

2021-01-19 18:05:14,100:DEBUG:certbot._internal.error_handler:Calling registered functions
2021-01-19 18:05:14,100:INFO:certbot._internal.auth_handler:Cleaning up challenges
2021-01-19 18:05:14,101:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/html/.well-known/acme-challenge/6J8rvDQ4YpLG9IITgDX5d1QTyB_qNDZoJ8hq3UOe9xY
2021-01-19 18:05:14,102:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/html/.well-known/acme-challenge/4gxyXW5b811TFdH27YRaF0Tq_AkwisO8YDFa7jKYpCU
2021-01-19 18:05:14,102:DEBUG:certbot._internal.plugins.webroot:Removing /var/www/html/.well-known/acme-challenge/8BpVN8ygR1IScbDHtc9aI2MWdLP1jyoU7sBHCguiwrE
2021-01-19 18:05:14,104:DEBUG:certbot._internal.plugins.webroot:All challenges cleaned up
2021-01-19 18:05:14,104:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 9, in <module>
    load_entry_point('certbot==1.10.1', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/site-packages/certbot/main.py", line 15, in main
    return internal_main.main(cli_args)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/main.py", line 1412, in main
    return config.func(config, plugins)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/main.py", line 1293, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/main.py", line 134, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/client.py", line 441, in obtain_and_enroll_certificate
    cert, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/client.py", line 374, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/client.py", line 421, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 91, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, best_effort)
  File "/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 180, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
AuthorizationError: Some challenges have failed.
2021-01-19 18:05:14,107:ERROR:certbot._internal.log:Some challenges have failed

There’s your problem–your server is refusing connections from the outside world. Fix that, and your cert should issue normally.

hmm… ok :slight_smile: now what?

found something… httpd-admin is not running…

httpd-admin.service - Server Manager UI httpd instance
   Loaded: loaded (/usr/lib/systemd/system/httpd-admin.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2021-01-19 18:47:09 CET; 4s ago
     Docs: https://github.com/NethServer/nethserver-httpd-admin
  Process: 24251 ExecStart=/usr/sbin/httpd -f /etc/httpd/admin-conf/httpd.conf -c MaxConnectionsPerChild 12 -DFOREGROUND (code=exited, status=1/FAILURE)
 Main PID: 24251 (code=exited, status=1/FAILURE)

Jan 19 18:47:09 domain.org systemd[1]: Started Server Manager UI httpd instance.
Jan 19 18:47:09 domain.org httpd[24251]: AH00526: Syntax error on line 62 of /etc/httpd/admin-conf/httpd.conf:
Jan 19 18:47:09 tank.domain.org httpd[24251]: SSLCertificateChainFile: file '/etc/letsencrypt/live/next.domain.org/chain.pem' does not exist or is empty
Jan 19 18:47:09 tank.domain.org systemd[1]: httpd-admin.service: main process exited, code=exited, status=1/FAILURE
Jan 19 18:47:09 tank.domain.org systemd[1]: Unit httpd-admin.service entered failed state.
Jan 19 18:47:09 tank.domain.org systemd[1]: httpd-admin.service failed.

this file /etc/httpd/admin-conf/httpd.conf still has entries to my old/deleted certs…