New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

letsencrypt acme-challenge 403 forbidden #1235

Open
szbnwer opened this Issue Jul 21, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@szbnwer
Contributor

szbnwer commented Jul 21, 2017

Operating System (OS/VERSION):

debian 8

VestaCP Version:

latest

Installed Software (what you got with the installer):

default

Steps to Reproduce:

nginx allowed (but not on the virtual host) + issue letsencrypt cert

Related Issues/Forum Threads:

a lot

Other Notes:

so i have problems with issuing a cert, therefore i started to track down the issue.
in v-check-letsencrypt-domain at line 90 if nginx is enabled then theres an unnecessary hack to give a standard response for anything in acme-challenge dir, i can see the files have been created up to this point, but when i wanna access acme-challenge directory, then i get a 403 forbidden response.

i've tried to switch to the else branch of the two if's related to nginx by writing false &&, but i've got nothing valuable result, and finally i got this error:
https://community.letsencrypt.org/t/unexpected-error-429/15713/4
the link says it should be the limit of 300 pending requests/week, right because this cron:
sudo /usr/local/vesta/bin/v-update-sys-queue letsencrypt
so maybe next time i can get more info, but the point above seems like the point of gettingevery time an error like:
Error: Fetching http://mydomain.com/.well-known/acme-challenge/ofSNtbf_rnButySaGFu0Rls40W6D9WfGiomd0W-h_h8: Timeout

i hope i could spot on anything valuable, and thx for any help! :)

@szbnwer

This comment has been minimized.

Show comment
Hide comment
@szbnwer

szbnwer Jul 29, 2017

Contributor

i have some progress, but https still not working...

so i've disabled the cron and changed from https://acme-v01.api.letsencrypt.org to https://acme-staging.api.letsencrypt.org and started to experimenting around...

i've found that the "Fetching http://mydomain.com/.well-known/acme-challenge/ofSNtbf_rnButySaGFu0Rls40W6D9WfGiomd0W-h_h8: Timeout" message was my fault, because i had an ipv6 assigned to my domain that was invalid (from previous usage), and acme wanted to fetch from that ip. so i've deleted it, and then i got back to the point where i was before when i got a dev server previously with a domain name... this is the same issue as this: https://petersproblems.wordpress.com/2017/07/27/vestacp-letsencrypt-error-invalid-response-from-httpmydomain-com-well-knownacme-challenge/ and i've found that what acme gives back is an error page for response from well-known... so i overcame it with that previously mentioned false && in v-check-letsencrypt-domain like this:

# Adding location wrapper for request challenge
if false && [ "$WEB_SYSTEM" = 'nginx' ] || false && [ "$PROXY_SYSTEM" = 'nginx' ]; then
    conf="$HOMEDIR/$user/conf/web/nginx.$r_domain.conf_letsencrypt"
    if [ ! -e "$conf" ]; then
        echo 'location ~ "^/\.well-known/acme-challenge/(.*)$" {' > $conf
        echo '    default_type text/plain;' >> $conf
        echo '    return 200 "$1.'$thumb'";' >> $conf
        echo '}' >> $conf
    fi
else
    acme="$HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge"
    echo "$token.$thumb" > $acme/$token
    chown -R $user:$user $HOMEDIR/$user/web/$r_domain/public_html/.well-known
fi

# Restarting web server
if false && [ -z "$PROXY_SYSTEM" ]; then
    $BIN/v-restart-web
    check_result $? "Proxy restart failed" >/dev/null
else
    $BIN/v-restart-proxy
    $BIN/v-restart-web
    check_result $? "Web restart failed" >/dev/null
fi

this means that it could be deleted without any problem (nothing else would be affected, as i observed the codes) or fixed, but i think even restarting the server didnt help any for that nginx hack on the go...

as you can see, i have an other fix above, this line:
echo "$token.$thumb" > $acme/$token
insetead of:
echo "$token" > $acme/$token.$thumb

just as well applied this:
exponent=$(openssl pkey -inform pem -in "$key" -noout -text_pub |\
instead of:
exponent=$(openssl pkey -inform perm -in "$key" -noout -text_pub |\
in v-add-letsencrypt-user

i hope i didn't change anything else

so i obtained the cert finally, i deleted it (i had problems for the 1st time with deleting, but i've tracked it down and deleted stuffs manually) switched back from staging (test) ecma api, now turn in/out letsencrypt works without error, and i can see the issued cert, key and pem files as well, but https still not working...

Contributor

szbnwer commented Jul 29, 2017

i have some progress, but https still not working...

so i've disabled the cron and changed from https://acme-v01.api.letsencrypt.org to https://acme-staging.api.letsencrypt.org and started to experimenting around...

i've found that the "Fetching http://mydomain.com/.well-known/acme-challenge/ofSNtbf_rnButySaGFu0Rls40W6D9WfGiomd0W-h_h8: Timeout" message was my fault, because i had an ipv6 assigned to my domain that was invalid (from previous usage), and acme wanted to fetch from that ip. so i've deleted it, and then i got back to the point where i was before when i got a dev server previously with a domain name... this is the same issue as this: https://petersproblems.wordpress.com/2017/07/27/vestacp-letsencrypt-error-invalid-response-from-httpmydomain-com-well-knownacme-challenge/ and i've found that what acme gives back is an error page for response from well-known... so i overcame it with that previously mentioned false && in v-check-letsencrypt-domain like this:

# Adding location wrapper for request challenge
if false && [ "$WEB_SYSTEM" = 'nginx' ] || false && [ "$PROXY_SYSTEM" = 'nginx' ]; then
    conf="$HOMEDIR/$user/conf/web/nginx.$r_domain.conf_letsencrypt"
    if [ ! -e "$conf" ]; then
        echo 'location ~ "^/\.well-known/acme-challenge/(.*)$" {' > $conf
        echo '    default_type text/plain;' >> $conf
        echo '    return 200 "$1.'$thumb'";' >> $conf
        echo '}' >> $conf
    fi
else
    acme="$HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge"
    echo "$token.$thumb" > $acme/$token
    chown -R $user:$user $HOMEDIR/$user/web/$r_domain/public_html/.well-known
fi

# Restarting web server
if false && [ -z "$PROXY_SYSTEM" ]; then
    $BIN/v-restart-web
    check_result $? "Proxy restart failed" >/dev/null
else
    $BIN/v-restart-proxy
    $BIN/v-restart-web
    check_result $? "Web restart failed" >/dev/null
fi

this means that it could be deleted without any problem (nothing else would be affected, as i observed the codes) or fixed, but i think even restarting the server didnt help any for that nginx hack on the go...

as you can see, i have an other fix above, this line:
echo "$token.$thumb" > $acme/$token
insetead of:
echo "$token" > $acme/$token.$thumb

just as well applied this:
exponent=$(openssl pkey -inform pem -in "$key" -noout -text_pub |\
instead of:
exponent=$(openssl pkey -inform perm -in "$key" -noout -text_pub |\
in v-add-letsencrypt-user

i hope i didn't change anything else

so i obtained the cert finally, i deleted it (i had problems for the 1st time with deleting, but i've tracked it down and deleted stuffs manually) switched back from staging (test) ecma api, now turn in/out letsencrypt works without error, and i can see the issued cert, key and pem files as well, but https still not working...

@twoup

This comment has been minimized.

Show comment
Hide comment
@twoup

twoup Sep 15, 2017

Contributor

This is the same problem as pull request #1236 - it is caused by a typo on line 58 of v-letsencrypt-add-user. Modify the file and change "-inform perm" to "-inform pem". See Pull request file for the full text to see the problem.

Contributor

twoup commented Sep 15, 2017

This is the same problem as pull request #1236 - it is caused by a typo on line 58 of v-letsencrypt-add-user. Modify the file and change "-inform perm" to "-inform pem". See Pull request file for the full text to see the problem.

@szbnwer

This comment has been minimized.

Show comment
Hide comment
@szbnwer

szbnwer Sep 15, 2017

Contributor

hi! i already obtained successfully the cert as i wrote above but the https is still unavailable, above i think i wrote all about my journey... but i'm aboutta getting out from that job i had around vesta, so i don't know if i will touch that remote server again or not where i worked...

Contributor

szbnwer commented Sep 15, 2017

hi! i already obtained successfully the cert as i wrote above but the https is still unavailable, above i think i wrote all about my journey... but i'm aboutta getting out from that job i had around vesta, so i don't know if i will touch that remote server again or not where i worked...

@twoup

This comment has been minimized.

Show comment
Hide comment
@twoup

twoup Sep 15, 2017

Contributor

Apologies - I see you ntoed you have modfied the code per my pull request. My bad!

Contributor

twoup commented Sep 15, 2017

Apologies - I see you ntoed you have modfied the code per my pull request. My bad!

@hostz-frank

This comment has been minimized.

Show comment
Hide comment
@hostz-frank

hostz-frank Oct 11, 2017

Thanks for your hacks on the issues!

Finally I am able to create e.g. a subdomain via VestaCP's web interface: I'm able to check now both the SSL and letsencrypt checkboxes at once, hit Save, and some minutes later (max. 5 min) the LE cert is successfully put into place. Please note, I'm talking about an Apache only install, so Nginx issues may still exist.

But first there was something still causing errors in my case. Even after changing the code due to @szbnwer 's suggestions (see above) there was a thing left: the simple lack of the acme-challenge directory. Inside v-check-letsencrypt-domain I inserted just before the line:
acme="$HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge"
this one:
mkdir -p $HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge
so that the challenge file could be written at all.

The else branch inside my hacked v-check-letsencrypt-domain, starting at line 98, looks like this, for now:

else
    mkdir -p $HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge
    acme="$HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge"
    echo "$token.$thumb" > $acme/$token
    chown -R $user:$user $HOMEDIR/$user/web/$r_domain/public_html/.well-known`
fi

This and fixing the typo in v-add-letsencrypt-user from -inform perm to -inform pem did the trick for me.

Thanks, guys!

hostz-frank commented Oct 11, 2017

Thanks for your hacks on the issues!

Finally I am able to create e.g. a subdomain via VestaCP's web interface: I'm able to check now both the SSL and letsencrypt checkboxes at once, hit Save, and some minutes later (max. 5 min) the LE cert is successfully put into place. Please note, I'm talking about an Apache only install, so Nginx issues may still exist.

But first there was something still causing errors in my case. Even after changing the code due to @szbnwer 's suggestions (see above) there was a thing left: the simple lack of the acme-challenge directory. Inside v-check-letsencrypt-domain I inserted just before the line:
acme="$HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge"
this one:
mkdir -p $HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge
so that the challenge file could be written at all.

The else branch inside my hacked v-check-letsencrypt-domain, starting at line 98, looks like this, for now:

else
    mkdir -p $HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge
    acme="$HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge"
    echo "$token.$thumb" > $acme/$token
    chown -R $user:$user $HOMEDIR/$user/web/$r_domain/public_html/.well-known`
fi

This and fixing the typo in v-add-letsencrypt-user from -inform perm to -inform pem did the trick for me.

Thanks, guys!

@szbnwer

This comment has been minimized.

Show comment
Hide comment
@szbnwer

szbnwer Oct 11, 2017

Contributor

oh fine, probably ive made the folder as well manually on the road...

btw ive used for reference the dehydrated le client, that ive became familiar when i hacked cpanel previously :D ive completely automatized le there before they made it, from pure userspace with cron dehydrated and a php callback with curl to login and install the cert mwhahaha (httpfox for the curl setup but the builtin inspector or wireshark can do the trick as well...)

Contributor

szbnwer commented Oct 11, 2017

oh fine, probably ive made the folder as well manually on the road...

btw ive used for reference the dehydrated le client, that ive became familiar when i hacked cpanel previously :D ive completely automatized le there before they made it, from pure userspace with cron dehydrated and a php callback with curl to login and install the cert mwhahaha (httpfox for the curl setup but the builtin inspector or wireshark can do the trick as well...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment