Nextcloud letsencrypt certificate

hi. back with a new nexctloud certificate question. nc is working - successfully installed a letsencrypt certificate
i dont understand this sentence on the virtualhost config page

If you’re using a Let’s Encrypt certificate, remember to add the host name below to the “Domains” field inside the “Server certificate” page.

which hostname? and where is the domain field on the cert page

thanks, philip

ps.: looks like i actually can reach nextcloud through the domain name. just complains about an invalid cert.

1 Like

The name you are using in the virtualhost.

Example:
You requested a letsencrypt cert for example.org.
Nextcloud uses https://example.org/nextcloud by default and is working correctly.
Now you set a virtualhost nextcloud.example.org and to make it work with letsencrypt you need to add nextcloud.example.org to the Domains field in the Lets Encrypt configuration.

hmm… ok still struggling with this.
i had requested a subdomain. next.example.org (not example.org, next.example.org)
virtual host settings -> vhostname and domain are set to next.example.org
submitting those nc vhost settings gives me an error “config not saved”.
conf.d/zz_nextcloud.conf has the correct domain in the 80 and 443 sections. i dont see any links to certs tough.
while looking through my old nexcloud notes i remembered that i was not allowed to request certs on my old system without a serverAdmin email entry in the conf files… which i dont see here on the nethserver system…

maybe im just too brain dead today…

thats the output of the error msg

echo '{"props":{"VirtualHost":"next.DOMAIN.org","TrustedDomains":["next.DOMAIN.org"],"Wellknown":"disabled"},"name":"nextcloud"}' | /usr/bin/setsid /usr/bin/sudo /usr/libexec/nethserver/api/nethserver-nextcloud/update | jq
{
  "steps": 3,
  "pid": 10679,
  "args": "",
  "event": "nethserver-nextcloud-save"
}
{
  "step": 1,
  "pid": 10679,
  "action": "S05generic_template_expand",
  "event": "nethserver-nextcloud-save",
  "state": "running"
}
{
  "progress": "0.33",
  "time": "0.088606",
  "exit": 0,
  "event": "nethserver-nextcloud-save",
  "state": "done",
  "step": 1,
  "pid": 10679,
  "action": "S05generic_template_expand"
}
{
  "step": 2,
  "pid": 10679,
  "action": "S30nethserver-nextcloud-occ-conf",
  "event": "nethserver-nextcloud-save",
  "state": "running"
}
{
  "progress": "0.67",
  "time": "5.601304",
  "exit": 256,
  "event": "nethserver-nextcloud-save",
  "state": "done",
  "step": 2,
  "pid": 10679,
  "action": "S30nethserver-nextcloud-occ-conf"
}
{
  "step": 3,
  "pid": 10679,
  "action": "S90adjust-services",
  "event": "nethserver-nextcloud-save",
  "state": "running"
}
{
  "progress": "1.00",
  "time": "1.418999",
  "exit": 0,
  "event": "nethserver-nextcloud-save",
  "state": "done",
  "step": 3,
  "pid": 10679,
  "action": "S90adjust-services"
}
{
  "pid": 10679,
  "status": "failed",
  "event": "nethserver-nextcloud-save"
}
{
  "id": "1601494076",
  "type": "EventFailed",
  "message": "See /var/log/messages"
}

The Nextcloud virtualhost must not be the same as the default domain. You need an additional domain (can be a subdomain) for the virtualhost.

If you only have one domain you do not need the virtualhost setting and can connect to https://next.example.org/nextcloud

Please check /var/log/messages for failed events.

thats what i found in the log
Sep 30 22:02:03 tank esmith::event[14854]: (Connection refused): IO::Socket::INET: connect: Connection refused
Sep 30 22:02:03 tank esmith::event[14854]: Action: /etc/e-smith/events/nethserver-nextcloud-save/S30nethserver-nextcloud-occ-conf FAILED: 1 [5.255526]

only need one domain right now. but that will change… its picking up the self signed cert from neth at the moment. lets say id go for one cert only, then i would need to delete the neth self signed one, and nc, ns would pick up the one left over?

OK, in this case you don’t need the Nextcloud virtualhost setting.

Neth usually uses one cert for all apps including Nextcloud.

You just need to request a letsencrypt cert in server manager with your domain name and set it as default, see documentation.

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.