Let's encrypt validation status

1

Oh oh, i’m sorry to make another topic…

I am out of options and tests but it’s giving me a headache now.
I’m trying to request a LE cert for a domain where i only changed the A record from the old server to the new server…

No idea why but it gives a validation error for that domain now.

I’ve checked letsdebug.net but that gives me a OK now.
I thought it was because i enabled Ipv6 but i’ve edited the vhost and it works, even the let’s encrypt file gives a 200 in the logs and is openable.
what can it be :confused:
The domain is: mbraamcreations.nl

Thanks in advance guys, im quite stuck :frowning:

2

You need to disable IPv6 dns records or the validation will fail - currently this is the only way.

3

Hm, can you explain why it fails cause I’ve added ipv6 to the vhost manually.
That does work, has it something to do with hestia needing to enable something.

I have found that in the user.conf it has a ip6:
That is empty. Since I’m running 1.1.0 already could this be the preparations for ipv6.

Id like to figure out how I could still get the cert while I have ipv6 enabled

4

The field is there since we forked it from vesta, IPv6 is on high priority, but needs also a lot of work :slight_smile:.

But basicly you’re right, the verification should work if you manualy edit the vhost (even I can’t recommend this, it’s better to create a own template).

Infact we do not support IPv6, I can’t help you out to tackle the problem down yet. As soon as we support it, Let’s Encrypt will also work.

5

Well I just edited the default.tpl and added the ipv6 address: [::]:80
So it did make the check work but it still let’s hestia give the error in the interface.

I will try to see if I can tackle the problem!

6

It isn’t a DNS validation issue, i think its something deeper…
I’ve removed the IPv6 DNS records… still getting the validation status error.
While I again see the entries into the access.log on ipv4.

Would’ve been nice if there was a better way to seeing an error. Now its just a error but doesn’t point a direction :confused:

After some more testing i see that it only appears when i do the letsdebug test.
There aren’t any 200’s shown in the acces.log when i request the log through the interface or v-add-letsencrypt-domain.

Could it be the user is broken or something?
I’ll try to remove the user add it from scratch to see what the results are going to be. Will post the results.

Edit 1 + result 1:
Tried to remove the domain from the user, added the domain again to be sure everything is “default” even then it doens’t show any 200’sin the fresh and empty domain.log.
It looks like there isn’t even a request for letsencrypt being made?

Going to test it on another user with another domain…

** edit 2 results **
I’ve tested it on another domain and it seems to be working. Weird, maybe it has to be due to the fact that there were some IPv6 dns records that has been removed. Will give it some time and see what happens if i request the LE later.
Still ain’t giving up :slight_smile:

** Edit 3 (fast results :slight_smile:)

After removing the user, the LE cert was being requested successfully. So it has to do something with the user or configuration of the user?
I am going to try to enable IPv6 and see what happens if i request the cert again from a newly created user and newly added domain.
Trying to find the solution that could help you guys implement IPv6 and LE :slight_smile:

** Good results **

After adding Ipv6 again to the DNS, checking if the records are already available and yes ( TTL on 300 )
I’ve succesfully requested the certificate even when i got IPv6 enabled. Curious why it does work now.

I’ve got the backup of the previous user, im considering to compare them to find out why this happened… but i don’t know what the important configs are for hestia.

For now my conclusion is that IPv6 is easy to enable just by adding the wildcard ipv6 adres to the templates. Just watch out that you dont do v-update-templates cause that overwrites the custom edits in /usr/local/hestia/data/templates…/php-fpm/default.tpl and such

7

Thanis for the debug updates, if you add LE_STAGING=“yes” to your hestia.conf, you will switch to the testing infra from Let’s Encrypt - this will prevent you to hit any limits, of course you will not get valid certs.

8

Thanks ScIT,
It doens’t even ask for a cert at this moment. So it seems like the let’s encrypt certifcate request isn’t being triggered due to a change i probably made myself some days ago.

At least we know for sure, if you add IPv6 to the virtual host, and request the certificate, it just works on IPv6 and IPv4.
Maybe it’s an idea to have a temporary enabled Ipv6? Everybody can add it themselves to enable Ipv6 for their server/domains/websites. untill it is fully implemented to HestiaCP.

I will try to figure out what i did wrong to cause this mess, since the issue is gone when i make a new user. This issue is 100% my own creation :confused:

Thanks for the extra thoughts about the LE testing. Think we can close this one.
If i got any more issues or things I walk against i will def, let you guys know!

For everyone that likes to enable IPv6 for their domains this is what I did to enable it.
(Nginx only)
add to the right templates:
listen [::]:80;

Then v-rebuild-web-domain [USER] [DOMAIN]
As far as i know this would just rebuild the virtualhost config from the template.
The website should be IPv6 ready :slight_smile: You just need to have AAAA records for www and the domain itself.
Remember if you use DNS through Hestia be sure to add the records yourself cause they ain’t automatically put in.

Oke no idea… can’t find it, after I moved back the backup it gave the same error.
Then i removed the user again. restored the backup but didn’t recover web only the rest.
Added the new domain through the panel and it worked.
Moved back the WEB from the backup.
Now it just gives timeout, but after running it 3 times it worked.
Well seems fixed for me lol

9

Thanks for the deep testing! Just a small note: Please create a own template if you modify them, they will get overwritten on a new release, same for vhosts.

We will completly support IPv6 including Let’s Encrypt as soon as we have implemented it.

10

Just a thought here… After changing a record in DNS it may take up to 48 hours for the change to propagate to other DNS resolvers around the globe. This might have been the case here.

I order to work around that, every time you need to make a change in DNS records I would suggest you to lower the TTL value of the DNS Zone to something like 300 (Hestia > DNS > Edit zone > TTL), wait at least 48 hours and then perform the changes on the records.

The TTL value is the time in seconds that other DNS servers will keep the records in their cache. DNS servers always look in their cache first for a record, and if they don’t have it, they’ll ask your DNS. Which means that even if you change a record, if other DNS servers have it in cache, they won’t even ask for the changed record.

11

@Raphael

There are default a couple of templates already like wordpress and such.
Is there coming a way to enable and disable them for usage?
Currently i just edited wordpress.tpl and wordpress.stpl.

If i create my own is it important to keep them in the same folder i guess so? But then I will have even more teplates :-)?

@Felix Thanks for your thoughts, the was already on 300 a week before I started migrating :slight_smile:

12

Yes, you will need to have them in the same folder.

I think 48hrs appends only to nameserver changes :slight_smile:, but I may be wrong; The TTL is the one that gives out the max caching time.

13

Cool! I will do that, and is there a way to turn off existing templates? Could be quite a mess for customers currently.

Yeah, for nameservers it was 48hrs out of my head.
But TTL is really caching. so TTL 300 means it goes really fast.
Even tho it can still happen that the DNS isn’t right in china and it takes a little loner to set, but that won’t harm LE request i think.