Require cert for www only, excluding naked domain

Help
1

My domain is: cykelos.com

I ran this command: Let’s Encrypt cert installation function within Plesk

It produced this output:
Error: Could not request a Let’s Encrypt SSL/TLS certificate for cykelos.com .

Go to http://cykelos.com/.well-known/acme-challenge/yQjjtWeyruoKTPpeGGuV9EOwohx0HtCg1yU2eBWDrxQ
and сheck if the authorization token is available.
If it is, try to request the certificate again. If the token is not available, there may be an issue with your DNS configuration.
Your domain in Plesk is hosted on the IP address(es): [hidden] , but the DNS challenge used another IP: [hidden] .
Make sure that the IP address(es) specified in the domain’s DNS zone match the IP address(es) the domain is hosted on.
If it does not help or if you cannot find an issue with your DNS configuration, use this KB article for troubleshooting.

My web server is (include version): Plesk Onyx v17.8.11_build1708180301.19 os_Ubuntu 16.04

The operating system my web server runs on is (include version): Ubuntu 16.04.6 LTS‬

My hosting provider, if applicable, is: Dedicated

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): Plesk Onyx 17.8.11

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

Hi Guys,

I’ve tried to find related posts on the forum without any luck. The question I have has bene posted elsewhere, with no resolution:

I use the Let’s Encrypt extension within Plesk for all my domains.

I have a client who requires the hosting of a website on https://www.cykelos.com hosted on my server (A), while an app is running on a different server (B) under https://cykelos.com. I.e. the DNS is setup so that the A record for cykelos.com points to the IP of server B and the A record for www.cykelos.com points to the IP of server A.

The app is established and the https://cykelos.com domain has a cert installed on server B. I’ve successfully installed a wordpress instance on server A under http://www.cykelos.com, but I’m unable to apply a cert against it, presumably because the service is trying to secure both cykelos.com and www.cykelos.com.

Is there any way to only secure www.cykelos.com on server A, without requesting the naked domain cykelos.com to be covered by the same cert request?

Your help is very much appreciated.
Thanks

1 Like
2

Hi @Municator

I don't use Plesk.

But that

looks bad. I don't see an option to exclude the main domain.

One idea: Try to create a subdomain test. Then check, if you have additional options to create a certificate only with test.cykelos.com. If that works, try the same with the www subdomain.

PS: Additional option: Use certbot and certonly to create a certificate, then import it manual. But that's terrible.

2 Likes
3

Hi @Municator,

Welcome to the community forum!

Check out this piece of documentation to issue a certificate for just www.cykelos.com https://certbot.eff.org/docs/using.html#changing-a-certificate-s-domains

1 Like
4

Hi @Phil,

Thanks for getting back to me so quickly, and also for the other feedback from @JuergenAuer. Much appreciated.

I had had a look at the documentation, but it seems that the area you suggested only applies to changing an already existing cert to include/exclude certain subdomains - unless I’m mistaken. On my server (A), I do not have a cert installed for the domain as yet, because of the errors described. So I’m having trouble with the initial issuing of the cert, rather than managing/changing the certs domains.

Running a command like the following (in an effort to only catch www. but not the naked domain):
certbot certonly --cert-name cykelos.com -d www.cykelos.com

Gives this output:
Domain: www.cykelos.com
Type: unauthorized
Detail: Invalid response from
https://www.cykelos.com/.well-known/acme-challenge/LjPiLPIQ38Kb-rmlrNBdVbW3HP6mjhXfOSRUoCOiiJg
[50.21.183.4]: “\r\n404 Not
Found\r\n<body bgcolor=“white”>\r\n

404
Not Found

\r\n
”

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.

Any suggestions?
Thanks again and in advance.

1 Like
5

What’s the IP address of the server where you ran that Certbot command?

6

Hi @schoen ,

IP is 50.21.183.4.

7

What method did you tell Certbot to use to authenticate your control over the domain name?

8

I used webroot to authenticate.
Note: I’m a first-timer doing this via the command line.

9

Your webroot was probably specified incorrectly, or else you probably have a rule in your nginx server configuration that doesn't allow files to be served from /.well-known/acme-challenge.

Before trying to debug your webroot selection, would you consider using certbot --nginx instead? It's much more automated and deals well with a fairly wide range of nginx configurations.

10

Sure, sounds good.
Would you mind pointing to installation and usage instructions?
Thanks so much for the help.

11

Okay, followed these instructions:

Ran this command:
certbot certonly --nginx --cert-name cykelos.com -d www.cykelos.com

Returned:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.cykelos.com

[then a long list of messages for every domain saying: nginx: [warn] duplicate MIME type “text/html” ]

Waiting for verification…
Cleaning up challenges

[then the same set of warning messages again]

Failed authorization procedure. www.cykelos.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://www.cykelos.com/.well-known/acme-challenge/2olevHCwBv9j4Glc2m4OKGMmi-bTo6SxMPvhcZnXSkU [50.21.183.4]: “\r\n404 Not Found\r\n<body bgcolor=“white”>\r\n

404 Not Found

\r\n
”

IMPORTANT NOTES:

12

Again, just to clarify: At the DNS level, there’s an A record for the naked domain pointing at a remote server (B), and an A record for www pointing at my server (A). If that makes any difference.

13

As for my knowledge, that does make a difference and probably is causing your error, you run the challenge on server B, but that IP does not validate in DNS for the domain on server A which has a different IP.
The challenge has to be made from the server that is hosting the domain you want to validate. So for getting the certificate for your www domain, you have to run the service on the server for that domain.

14

@Municator, I was trying to ask about the same concern that @ferdiS is raising—do we understand properly that you are running the Certbot commands on the server whose IP address the www record is pointed to?

15

Hi Guys,
Yes, most definitely, I am running these commands on server A, the one where www is pointing and resolving. I don’t have access to server B, where the naked domain is pointing.
Is the command I’m running the correct one?

16

I don't know. The main problem: You use a Plesk, so Plesk has it's own domain management.

So I don't think the standard --nginx authenticator works, Plesk may have it's own configuration.

What's your root definition in your port 443 vHost? Normally, you need the port 80 vHost, but you have a redirect http -> https.

Create the two subdirectories

yourroot/.well-known/acme-challenge

there a file (file name 1234), then try to load that file via

https://www.cykelos.com/.well-known/acme-challenge/1234

to see, if it works. If yes, use

certbot -a webroot certonly -w yourRoot -d www.cykelos.com

to create the certificate (add your other parameters).

17

Thanks for the advice @JuergenAuer.
I have control over the DNS, so what I just tried is to temporarily point the naked domain A record to my server (A), and apply the certificate through the Plesk interface via the Let’s Encrypt plugin. The cert was successfully applied, after which I quickly reverted the naked domain’s A record back to server B. This seems to have done the trick, but I’m sure the auto renew will fail of course. At that point I’ll either try your suggestion, or do the same trick again.

1 Like
18

That's possible. But that interrupts your main domain and your app, so it's not really a solution.

19

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