Hardware: Other ARM board / … YunoHost version: 11.2.5 I have access to my server : Through SSH Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes If yes, please explain: my_webapps, to run websites/apps with own domains on my ynh.
Description of my issue
Hi again ynh,
So I’m unable to automatically update the https certs for own of my my_webapp websites on ynh. it’s a simple static site with its own domain and some basic nginx config.
the diagnosis error is:
Domain anarchive.mooo.com appears unreachable through HTTP from outside the local network.
It looks like another machine (maybe your internet router) answered instead of your server.
1. The most common cause for this issue is that port 80 (and 443) [are not correctly forwarded to your server](https://yunohost.org/isp_box_config).
2. On more complex setups: make sure that no firewall or reverse-proxy is interfering.
because of this check, certs update fails. if i do updates via ssh/CLI, it works when i add the --no-checks flag.
i don’t know why this check needs to block the update. my box is accessible via http with all the other domains, so it is not a problem with port forwarding.
and for this particular domain, i force HTTPS in my nginx conf, by using:
server {
listen 80;
listen [::]:80;
server_name my.domain.com
# ... other config here...
location / {
return 301 https://$http_host$request_uri;
}
is this the cause of the diagnosis error?
i have had issues with this before:
due to them i disabled ipv6 on my router and server. again, i don’t see why i need to have ipv6 working flawlessly merely in order to automate updating HTTPS certs?
if this is only only hiccup, can i permanently disable this particular check before updating certs? i don’t want sites to break for these minor reasons. my site otherwise works perfectly fine.
It blocks the certificate renewal because, by definition, if this check does not pass, the certificate renewal is very unlikely to be successful
I’m not sure to understand why you need to enforce HTTPS : YunoHost already enforces HTTPS … actually the snippet you are showing is from the default config so i’m not sure to understand … however there are other specific snippets which should exist in the configuration, namely:
include /etc/nginx/conf.d/acme-challenge.conf.inc;
location ^~ '/.well-known/ynh-diagnosis/' {
alias /var/www/.well-known/ynh-diagnosis/;
}
and diagnosis and/or cert-renewal won’t work properly without these
Does yunohost tools regen-conf nginx --dry-run --with-diff shows anything specific ?
i do have the snippets you mention in my conf, i just didn’t quote them, sorry.
i tried the command you suggest, got a lengthy diff, so i backed up the config file and ran the command minus --dry-run, then restarted nginx. (i avoid updating my nginx files because then when ynh updates it often breaks my sites manual config.)
but web diagnosis still returns the same error.
is there anything else that might at risk of causing the issue? as i mentioned, it’s not port forwarding because all other domains work fine. (i checked my router and 80/443 are forwarded.)
if you say ynh already forces https, should i remove that config?
and as mentioned, ipv6 is disabled on the router.
can i run the http check manually somehow while still redirecting to https?
If you manually modified files, then you need to use --force to effectively apply the changes, otherwise it just says that the file appears to be manually modified and won’t be updated by yunohost … but it would be nice to know what you did modify in the first place, otherwise we are just brute-forcing the issue without understanding what’s going on, hence the recommendation to look at those with --dry-run --with-diff
i just saw my manual conf is in the domain.com.d/my_webapp.conf subdirectory and file. is it possible to keep all manual config in there and then happily override the domain.com.conf?
i actually think all my manual config is in there. all i needed to do was have an nginx fancy index config for a file listing on my site.
I don’t know, that depends what you are trying to achieve exactly, that syntax doesnt even look like a valid one … but yes, files in domain.tld.d/*.conf are included in the domain conf … or you can also imagine tweaking security.conf.inc too