DirectAdmin Certbot request failing 404 with Apache

Help
21

i see a randon comma there..

22

Do not modify that file ! The syntax is very fussy. The comma is fine. Minor changes can cause significant problems.

The webroot_path is where DA has told Certbot to place the challenge token file. But, the "404" in the error means your Apache is not finding that token file in that location.

Do you know how to control the DocumentRoot setting in your Apache VirtualHost for this domain?

1 Like
23

think so, the directives

24

and we may be on to something, seems some other software injected stuff

25

Is that the same path as in those directives?

btw, I changed the title of this thread to highlight the key issues

1 Like
26

Perhaps in October :slight_smile: ?

1 Like
27 
Alias /.well-known/acme-challenge /usr/local/centovacast/etc/ssl/acme-challenges/.well-known/acme-challenge
<Directory /usr/local/centovacast/etc/ssl/acme-challenges/.well-known/acme-challenge>
    Options None
    AllowOverride None
    # Apache 2.4
    <IfModule mod_authz_core.c>
        Require all granted
    </IfModule>
</Directory>
28

document root seems right
DocumentRoot /home/turbodj/public_html

29

commenting out that alias allowed the dry run you posted earlier to run with success

1 Like
30

Good. So will the actual renew. Try that now.

1 Like
31

says not secure but seems the site is actually working again, and it did update this time with no error

32

A new cert was issued and your server is using it. Try restarting your browser. They sometimes cache prior certs.

It looks good to me and other testing tools

2 Likes
33

Seems to be working, thank you so much! now i get toi se what all that alias broke

2 Likes
34

Yeah, you'll want to ask the centovacast people why they put that in there. That was trying to control the certificate requests. But, in DA not sure why you'd have some other system doing those for same domain.

2 Likes
35

i do have the main server using let's encrypt and then a virtual one also using the same domain, the main server being the single turbodj.com one

36

Not quite sure what you mean by that. An HTTP(S) request directed to your system has to end up somewhere.

Sometimes there are load balancers or CDNs or such in more complex environs but I didn't see any evidence of those here.

You can also do NAT or port forwarding or similar routing things but an HTTPS request is "terminated" by something that needs a cert. This Apache server in this case. That is, something has to see that HTTPS request (your Apache) and setup the encrypted comms using that cert. You can then have Apache proxy that request to another server but that wouldn't have to use HTTPS. Designing server configs is beyond the scope of this forum pretty much. Maybe this is helpful anyway.

2 Likes
38

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