But the cloud comes up with a certificate warning saying that the cert was issued for ‘host-06238.ns8.test’. It looks like a self-signed certificate. Why is the letsencrypt certificate ignored? How can that be used?
We are now half way in Beta 2. But this problem is still the same. Where do those weird certificates like actually ‘host-24426.ns8.test’ com from and how can I replace them? Nextcloud is configured to use a Letsencrypt certificate but keeps being rejected on behalf of this invalid ERR-CERT_AUTHORITY,
The name is auto-generated from the container. The certificate is serve by traefik which has its own self-signed certificate. If Let’s Encrypt creation is successfully, the valid certificate automatically replaces the self-signed one.
So, if you’re hosting your nextcloud instance at cloud.hassun.xyz, make sure the domain is reachable both on port 443 and 80 from the public (from a quick test with curl it does not seems so).
The NS8 host sits in a dmz. The firewall forwards port 80 and port 443 connections per NAT to the NS8 address. Please tell me, what is wrong with that.
I also use NS8 in the DMZ.
In UTM I added two rules for WEB and I don’t encounter any problem with obtaining the Let’s Encrypt certificate (so far):
Incoming: WAN to DMZ port forwarding: 80; 443
Outgoing: DMZ to WAN: 80; 443, 53 (TCP+UDP)
Bumping this one, the self signed certificate is bogus and not professional e.g. ‘host-06238.ns8.test’
It reveals too much information
Using ‘test’ in a name is not professional, please leave that up to the user of NS8. The label part ‘test’ can have a very different meaning within an organization. Pls keep it agnostic.
The number part of the host does not ring a bell to anybody, not even the installing person.
Can it be something more generic for mistakes with LE do happen and then th end-user should see a more professional certificate name, but not revealing OS, distribution or anything else that can be (mis)used.