Certificate on sub domain, main domain pointing to different server

Hi there,
I run a plesk server and for mydomain.com the A record is pointing to a nextcloud installation on an external server. The external server has it's own certificate.

My mail and webmail is still on the Plesk server. When renewing the LetsEncrypt we run into a status: 403. Invalid response from [http:/mydomain.com/.well-known/acme-challenge/hxy7X...

On the nextcloud server: can i make a redirect to the plesk server? And what will such a redirect look like? Sorry, not so technical...

Thanks in advance

How does that work if the hostname is pointing to a different server?

3 Likes
mail.mydomain.com.		A		xx.xx.xx.01 -> Plesk
webmail.mydomain.com.	A		xx.xx.xx.01 -> Plesk
mydomain.com.			A		xx.xx.xx.02 -> Nextcloud
mydomain.com.			MX (10)	mail.mydomain.com. -> Plesk

In that case it would make sense to have separate certificates, one for the mail and webmail subdomains through NextcloudPlesk and one for your apex domain (possibly with the www) subdomain using PleskNextcloud.

5 Likes

Why did NextCloud not get its' own [subdomain] name?

2 Likes

In retrospect that would have been better, but now we have to deal with the situation as it is

The situation is always as you want it.
If not, then you need to regain control of it.
How do you want the situation to be?
If like this, then we can continue down this path.

  • Each FQDN should point to a unique IP [:heavy_check_mark:]
  • Each server (at each unique IP) should obtain a cert for its' name(s) [pending]
4 Likes

You have given me something to think about. I'm going to sleep on it

Just getting two separate certs? I wouldn't sleep too long on that, isn't that much of a decision IMO :stuck_out_tongue:

5 Likes

One cert that covers names with different IPs is not really useful.
Possible... but why? Unnecessary overcomplication.
Separate IPs = separate certs [simplest solution]

5 Likes

two separate certs is not some thing i have to sleep on, it's the way I have to implement it. As told, not so technical. I'll give it a try tomorrow. Thanks for your input.

2 Likes

Ah ok, makes sense. Personally I don't have experience with Nextcloud nor Plesk, so I'd also need to sleep on that :stuck_out_tongue:

5 Likes

I tried two things, both of which did not work.
First, I removed the certificate from the apex domain in Plesk. This is because it is redirected to the external nextcloud server and has its own cert there.

Then I created a subdomain in Plesk: mail.mydomain.com. I can attach a letsencrypt cert. to that, but the DNS of the subdomain redirects to the nameserver and that results in an error in the mail applications "Mail can't verify the identity the identity of mail.mydomain.com"

I also can't just attach a certificate to the mail/webmail from the apex domain, because Plesk/Letsencrypt then selects the main domain as well.

Normally I just link a LetEncrypt certificate to a domain in Plesk and it works perfectly. Now it is just a little different and I am not technical enough to see how this can work. Hopefully you have another suggestion

Hope I describe the problem correctly, English is not my first language

Can you remove the apex domain from Plesk altogether?
Make the name only mail.example.com.
Then host and secure that domain only.
[use that one name for actual mail and also for web based mail access]

3 Likes

Nah, didn't work out because there are mailboxes on the apex domain, than we have to migrate all those mailboxes to the subdomain and instruct the clients to reconfigure stuff... Mailclients didn't accept the certificate attached to mail.domain.com (Is that because the mailserver is on mail.mail.mydomain.com? Not sure about that.)
We migrated the Nextcloud to cloud.mydomain.com. Should have done that in the first place, thanks for all your suggestions :slight_smile:

2 Likes

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