How can I change a certificate name?


#1

I am currently running a nextcloud for my personal use - its the ubuntu appliance version I got from techandme some time back.
I am very green to linux - actually my ‘skill’ is blindly copying and pasting commands and hoping they are doing what I want.

How I’m currently setup:
My Fritz router handles the DNS registration https://update.dedyn.io/ for my domain dlmw.dedyn.io

When I fumbled around getting certificates installed for https, I just ran the certbot commands on the nextcloud server. All works just fine :slight_smile:

but…the nextcloud server is effectively hosting the dlmw.dedyn.io domain, which I don’t think is correct (feel free to disagree). Indeed, when I configure the clients, they point to dlmw.dedyn.io

I’m thinking that it should be using a certificate such as nextcloud.dlmw.dedyn.io instead.
Reason being, I am planning to have a play with nginix on a separate VM, and I assume if I go certbot, it’ll get issues trying to have the same domain.

I think I should have nextcloud.dlmw.dedyn.io and nginx.dlmw.dedyn.io, for example.

Am I correct in this, or am I looking at it incorrectly?

If I am correct, then I need help for two things…

  1. how to de-certify/deregister the existing certificate on the nextcloud server
  2. how to re-configure it to go get the new certificate

My domain is: dlmw.dedyn.io

I ran this command: N/A

It produced this output: N/A

My web server is (include version): Server version: Apache/2.4.29 (Ubuntu)

The operating system my web server runs on is (include version): Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.28.0


#2

first of all, you will need to point nextcloud.dlmw.dedyn.io to same ip with dlwm.dedyn.io. are they give you access to those sub-subdomains at all?


#3

:joy: that is a very good point. nope, dedyn don’t seem to support sub domains :confused: I’ve just signed up for the beta access of DNS hosting so maybe that’ll allow more config.
Else, I guess I need to find another provider


#4

This depends greatly on what the dedyn.io service can provide you.
If you can create FQDNs larger than just dlmw.dedyn.io, then you are half way there.
[but I don’t yet see an IP resolving to either f those larger names]

Once you can get DNS to resolve the new names, you would modify the instructions you followed to include (or replace them with) these new names.
[if replacing, you might want to also delete any unused cert(s)]

I guess this is a disagreement…
The name that is used is irrelevant.
The Nextcloud software does not require the word “nextcloud” to be used in the FQDN it serves from.
[any unique name that resolves to an IP that can reach that server will do]


#5

Perhaps I did not explain myself. My thought was around having the domain effectively point to my router (by example) and then having the subdomains/hostnames resolved by the router.
By typing this out, I’m realising I’d need a SOA (at least my router will need to be a nameserver) which dedyn.io doesn’t support I think.

But perhaps I’m coming at this incorrectly…
My goal would be to have multiple webservers. Actually, I realised I already have a 2nd one for another app running off a different port. So I could just separate by port number and the router will forward as appropriate, with the default being nextcloud.
The ‘problem’ with that, is that they would all effectively be dlmw.dedyn.io and I’m guessing that that would be a problem for granting certificates? (at the moment that second app is only accessible by IP address and non-ssl)

I guess I can create a new DNS entry otherapprandomname.dedyn.io for each server and go from there. Just they’re then not related. Maybe I need to stop being tight and buy a domain :confused:


#6

You could copy the certificate and key from one system to another because the certificate isn’t specific to a particular TCP port. But otherwise, yes, if you want to start having different DNS names to refer to different machines or services, you’ll probably need to get a DNS setup that will permit that!


#7

So…I’ve change DNS provider and ‘fixed’ that problem;


With the router registering the bundykids.crabdance.com

All good…except…
I have an emby server (on windows) that I thought might be nice to add - but in order for the certify app to grab a certificate, I had to point port 80 at emby…at least I think I do? which would then break cerbot for automated renewal, right?


#8

Yes, are they on the same IP address? Could you get the certificate with Certbot and then transfer it over to the Windows server somehow?


#9

If the Linux system can proxy http requests, then you can complete the authentication loop.
[Windows to LE - LE to Linux - and Linux passthrough to Windows system (for all http://emby requests)]


#10

Externally, yes

I think that’s my next investigation route. I’m thinking I can maybe leverage nextcloud itself…if certbot gets the emby cert, and copies/moves it to a folder that is within a user folder in nextcloud, then a nextcloud client on emby can be set up for that user and sync the folder - which brings it locally to emby. then, the emby web points to local folder for the certificate.

At the moment I got no idea. I wanted to play with nginx and I know it does reverse proxy etc, and it’ll also be able to check the incoming request and direct accordingly. I think I need to do some basic linux admin training :confused:


closed #11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.