SSL certificate for panel (:8083) outdated and different that certificate for domain name [SOLVED]

1

The address https://mydomain.com is using a right certificate (it has been already updated successful several times), but https://mydomain.com:8083 is using an expired certificate. It should be updated yesterday, but id didn’t.

I don’t know if it’s due to the update of Hestia to v.1.4.11 just yesterday too or due to the expiring of the SSL certificate JUST ALSO yesterday.

So i’ve 2 doubts:

  • a) is it required to use 2 different certificates for 2 different ports?
  • b) in affirmative case, why Hestia has not updated the :8083 certificate?

I don’t like ask on forums before to deeply search on forums. But certainly i’m already without options/answers.

a) As i read “there”, the same certificate for a domain.com is USABLE for any port. So, HestiaCP (nginx?) should serve the answer to mydomain.com:8083 taking the SAME certificate than for the default web requests for that domain? I don’t know enough about the marriage of HestiaCP-Nginx, and maybe it not depends on hestiaCP management, but on Nginx configuration.

b) (doubt) How does it know NGINX which domain name will be used on browser to users access to HestiaCP if there are more than one domain names hosted in the same HestiaCP? In my case, following recommended good practices, i created my domain name under a NOT-ROOT user. But other users could create other domain names. Then, HestiaCP (:8083) is accessible through all of these domain names? What happens then with the SSL certificates.

@eris Suggested to me run this command (when i explained all this as comment of another topic):

v-add-letsencrypt-host

But this didn’t solved the question. In fact, i found a new problem (not directly related with this topic… or maybe it is!?): when running this command Hestia try to renew a Letsencrypt certificate for a NON-EXISTING domain name: mydomain_old.com which i created far far away and i removed from Hestia almost a year ago.

For mysterious reason it survive in a black whole, hehehe, and appears again! I have removed 3 times some minutes ago -before write here- and after executing the above command the domain name APPEARS AGAIN under de default “admin” user of HestiaCP and… causing a fail in the certificates renew process.

Then i tried this other similar command:

v-add-letsencrypt-domain 'my-not-root-user' 'mydomain.com'

And it successfully renewed the Lets Encrypt certificate for that domain (the unique hosted on my server), but didn’t altered the domain used for mydomain.com:8083

My apologies for be so exhaustive with my explanations, but i understand that in this way is easier for you to helo me. Thanks again!

2

Please setup a propper hostname for your server, mydomain.com isnt one. Probaly web01.mydomain.com fits better. There are potential issues with using mydomain.com in a different user account, also some other points due to the “invalid” hostname.

3

This is the against the recommend by my hosting provider (and i already have read in other blogs): assign a hostname for your server which not match with your main domain name or a non-hosted domain name in this server will cause heavy problems for SMTP servers and PTR and blacklist problems. They recommend to use as hostname the domain name hosted.

So… i’m not very sure about the convenience of change now my hostname because a problem with LE certificate for :8083

Please, if you have another suggestion, please tell me.

4

In my experience it is not the case.

I use as hostname: mail01.mycompany.com

And I send emails on behalf of client1.com upto client137.com without issues (when configured properly)

Some of my clients send over 500 emails per morning.

Bear in mind that I can potentially host DNS in one machine, the web in another one, the database in a third one, SMTP in a fourth one and IMAP in a fifth one.

In such context when one says

It makes no sense to me.

5

Thanks by your optimistic comment, but i prefer not touch the hostname of my server. I’ve put many effort during the last 12 months to get a good smtp reputation, and sincerely, i want to avoid “experiments” regarding to it.

Said this, i must remember to you that this problem with SSL certificate for mydomain.com:8083 arised NOW… in other words: it was no problem regarding this the last 12 months… with the current hostname.

I can understand that it could “help” to have another hostname, but let me insist: until a week ago there was no problem with the current hostname.

So, let me ask again (i’m sorry but you both has not answered none of my 2 questions): what about this issue with SSL certificate served by my server with HestiaCP, serving different SSL certificates for :8080 port and :8083 port… Is this a bad management by hestiaCP ? or a missconfiguration of NGINX ? or a malfunction of the updating Let’s Encrypt certificates?

Furthermore, what about that second mydomain_old.com that IS ADDED to the user ‘admin’ on Hestia when i run the command v-add-letsencrypt-host ? That domain name was the first one i added to this server, but i never used anymore and i replaced it with the current mydomain.com. In some way that old domain name must be stored in some kind of “cache list” used by the v-add-letsencrypt-host script, because it is being retrieved with no-sense!

So please: can i clean my hestiacp about this old domain name? it’s very likely that this error is behind of the failed LetsEncrypt renewing process, instead to have realtion with hostname.

6

Let me share the output when running the v-add-letsencrypt-host command:

v-add-letsencrypt-host
Error: Let's Encrypt validation status 400 (mydomain_old.com). Details: Unable to update challenge :: authorization must be pending
Error: Let's Encrypt SSL creation failed

So, clearly, it’s quite likely that this problem running this command is the reason for the expired certificate being served on mydomain.com:8083, do you think the same?

Please help me to solve this issue with this “phantom” domain name arising from the “past” :wink:

Thanks guys. I’m almost sure that it’s some kind of odd cache.
Indeed, i tried to empty the content of this file (recommended by one of you in other topic in this forum):

 nano /usr/local/hestia/data/queue/letsencrypt.pipe

but it continue empty and the problem continue happening. So clearly it doesn’t help. But i suspect that the problem likely is something like this.

7 
v-change-sys-hostname  newdomain.com
v-add-letsencrypt-host

Then delete the old hostname from admin.

In case if the hostname is on an other user account v-add-letsencrypt-host should detect that and work just fine.

1 Like
8

This just dont make any sense, so google/gmail would have to use gmail.com as hostname for multiple servers?! There is no otherway, use hostname.domain.tld as it should be and you will not have any issues - that’s the way to go, there is no other, using domain.tld is just badly wrong.

You can follow the steps provided by @eris above to change the hostname, be sure you’ve created a proper dns record for hostname.domain.tld (hostname = whatever you want, for example web01) before you run v-add-letsencrypt-host.

3 Likes
9

Again the same error on terminal:

v-add-letsencrypt-host
Error: Let's Encrypt validation status 400 (mydomain_old.com). Details: Unable to update challenge :: authorization must be pending
Error: Let's Encrypt SSL creation failed

Even if i go through hestia (browser) and delete the unique domain name of the ‘admin’ user mydomain_old.com. When executing the above terminal command it returns that error and appears again in the web browser that domain name i deleted one minute ago!

I think that it would help me if you tell me where could be stored that deprecated domain name. In which cache file or something like this. My spider sense says that it has not relation with hostname. But guys, you’re the master, not me.

10

I really appreciate your effort for help me. Seriously, i’m feeling bad with you, But beleive me:

a) I don’t want to change my domain name.Probably you’re right regarding not danger for my email reputation. But sincerely: i prefer don’t tu take any risk… i use this for serve marketing sendingn emails for more than 50 customers. Beleive me: i will try to make any change like this. My unique PROBLEM is the certificate to access hestiaCP in :8083 port. It doesn’t compensate the risk

b) Even more: a month ago i had this current hostname and there was NONE problem with certificates so: 1) it’s an undoubted true that it can run with current settings, 2) it’s not impossible o “just badly wrong” as you said in your last comment.

Man, seriously, why is it arising that mydomain_old.com domain name again and again attached to the ‘admin’ user when running v-add-letsencrypt-host ??

11

I decided to follow the steps of the command:

v-add-letsencrypt-host

I found the first odd behaviour. I run this command (suggested by @eris) to set hostname:

v-change-sys-hostname mydomain.com

And after that i run the line #20 of the v-add-letsencrypt-host script:

$(hostname -f)
mydomain_old.com: command not found

So, as i understand it, the hostname was not changed with the first command and continue being the old one.

I understand that if it’s so, then the rest of the script cannot run fine, because obviously that old domain name is not hosted there.

If you prefer not answer yet, let me continue with my tests. I will comment again when i got it run or desisted :wink:

12

Honestly, I’ve wrote you how to solve your issue without any risk - do it like it is susposed to work or leave it. I’ll not invest more time in this case…

13

First of all:

v-change-sys-hostname domain.com

Will change run:

hostnamectl set-hostname $domain
echo "$domain" > /etc/hostname

So if you run:

$(hostname -f);

You will execute the command and that is not what you want

Run echo $(hostname -f); and it should show the hostname.

I have tested a ton of different servers and haven’t seen the issue. I now Proxmox doesn’t really like you changing the hostname. And resets it after reboot. I don’t know about other virtulasation software. But we can’t test everything…

2 Likes
14

Thanks. When you has wrote i was playing with just hostname “analysis” (insist on avoid to change different to my main domain hosted… sorry).

And effectively, the correct command is simply: hostname -f (i found this interesting guide 5 'hostname' Command Examples for Linux Newbies) and i discover that i’m too much newbie to this “hostname” manipulation tasks :frowning:

I read in that guide that the command hostname certainly make changes not-permanent, ie. they vanish after the next reboot of the machine !? They suggests to use hostnamectl instead.

Returning to my machine, these are the outputs for this 2 variants of the command:

hostname
mydomain.com
hostname -f
mydomain_old.com

I really don’t know enough (yet) to understand these answers. I’m reading on it just now. But if you have any suggestion, please… tell me how to permanently erradicate any mention of the mydomain_old.com in my “hostname”.

And again, certainly many thanks to be there!!

15

I know with Proxmox I get:

hostname -f
test.xxxx.xyz

hostname
test

16

Probaly old hostname in /etc/hosts.

2 Likes
17

Effectively, this was the problem!!

I had this:

127.0.1.1 mydomain_old.com mydomain_old mydomain.com

So: 1) the old domain name, 2) the old hostname, 3) the current domain name (& hostname)
I edited that file:

sudo /etc/hosts

and modified that line to:

127.0.1.1 mydomain.com

Then rebooted the server and then this were the hostname outputs:

hostname
mydomain.com
hostname -f
mydomain.com

Then i run the Hestia command:

v-add-letsencrypt-host

and this time all worked fine (empty output… so no problems). And i reloaded the mydomain.com on browser and voilà! the server is serving a NEW certificate with today emission date :wink:

Notes for other people: the file /etc/hosts can be automatically changed on reboot depending on your VM provider, because they put on your machine some scripts to automatize settings like these in the virtualized machines.

Comment/question for HestiaCP developers:

Would it be a good idea to modify the command v-add-letsencrypt-host to check if the domain to be “certified” is really hosted in this server? Yes, i know that a problem like mine could be very uncommon, but probably i’m not the unique user who has suffered a missconfiguration like this regarding to the hostname. Would be easily check-able this domain being hosted (obviously not looking for the hostname output)?

Anyway, many thanks guys for your tireless effort to help. I’m in debt -more!- to this community. Thanks @eris and @Raphael and @jlguerrero .

1 Like
18

Just to inform: We discussed the behaviour of using domain.tld as hostname in our dev chat. According to the rfc standard for hostnames (rfc1178) it’s not suggested at all to use a domain as hostname:

  Avoid domain names.

     For technical reasons, domain names should be avoided.  In
     particular, name resolution of non-absolute hostnames is
     problematic.  Resolvers will check names against domains before
     checking them against hostnames.  But we have seen instances of
     mailers that refuse to treat single token names as domains.
     For example, assume that you mail to "libes@rutgers" from
     yale.edu.  Depending upon the implementation, the mail may go
     to rutgers.edu or rutgers.yale.edu (assuming both exist).

So your provider is clearly wrong here, also we will restrict for feature installers to use domain.tld as hostname.

2 Likes
19

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