Skip to content
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

Active Http #14

Closed
foch01 opened this issue Dec 23, 2018 · 5 comments
Closed

Active Http #14

foch01 opened this issue Dec 23, 2018 · 5 comments

Comments

@foch01
Copy link

foch01 commented Dec 23, 2018

Hello,

At the execution of letsencrypt-init.shI have this error:

   Domain: MY_DOMAIN
   Type:   unauthorized
   Detail: Invalid response from
   http://MY_DOMAIN/.well-known/acme-challenge/ofzV3Ho4o2jQmwdsaJ9XAeVyl9bufnXaGrrC2sB3VSs:
   "<html>\r\n<head><title>404 Not
   Found</title></head>\r\n<body>\r\n<center><h1>404 Not
   Found</h1></center>\r\n<hr><center>nginx/1.15.7</ce"

   To fix these errors, please make sure that your domain name was
   DNS A/AAAA record(s) for that domain
   contain (s) the right IP address.

The ip address of my server is well associated with my name of domain, I access very well in http.

@mjstealey
Copy link
Owner

@foch01 - Couple things to look at

NOTE: I'm going to assume that MY_DOMAIN is just a placeholder, and that in your code it's a fully qualified domain name.

The response you received is actually coming from an Nginx server, so it appears to be close. Just a matter of making sure it's the correct Nginx container being hit.

  1. Make sure the docker-compose.yml based containers are not already running when you are initializing your certificates. There is the possibility of confusion if both the site Nginx container and the initializing Nginx container are running at the same time.
  2. Permissions might need to be looked at for the mapping of the .well-known location. This shouldn't be an issue, but not knowing what OS you are spawning on you may need to temporarily expose rw access to all until the initialization process has taken place.
  3. All transactions into and out of the host are taking place on port 80. Again, shouldn't be an issue because this is the default behavior, but if somehow port 80 of the host is already being used by something else you could see this issue.

@foch01
Copy link
Author

foch01 commented Dec 23, 2018

Hello @mjstealey ,

Thank you for your quick reply !

To explain everything, in letsencrypt-init.sh I changed cd $ {REPO_DIR} paths to cd $ {LE_DIR} because it could not find the docker-compose.yml when I was running ./letsencrypt/letsencrypt -init.sh MY_DOMAIN
But I do not think the problem is due to this

Yes 'MY_DOMAIN' is my domain name. I did not want the posted in this post ;)

  1. No container docker turns on my machine

  2. I am under a debian VPS

  3. There is currently nothing that is being used on port 80 of the server

@mjstealey
Copy link
Owner

@foch01 - Looks like you may have found a documentation error regarding where to run the initialize script from...

Try running from within the letsencrypt/ directory instead of the top level of the repository.

cd letsencrypt/
./letsencrypt-init.sh $(hostname)

If that is still failing you can also manually step through the initialize process from within the certbot/certbot container after it's launched by the script. That way if errors are encountered you have a better chance of seeing where exactly it fails.

Modify https://github.com/mjstealey/wordpress-nginx-docker/blob/master/letsencrypt/letsencrypt-init.sh#L55-L61

From:

docker run -it --rm \
  -v ${CERTS}:/etc/letsencrypt \
  -v ${CERTS_DATA}:/data/letsencrypt \
  certbot/certbot \
  certonly \
  --webroot --webroot-path=/data/letsencrypt \
  -d ${DOMAIN_NAME} -d www.${DOMAIN_NAME}

To:

docker run -it --rm \
  -v ${CERTS}:/etc/letsencrypt \
  -v ${CERTS_DATA}:/data/letsencrypt \
  certbot/certbot \
  certonly --manual

And follow the prompts

@foch01
Copy link
Author

foch01 commented Dec 30, 2018

The problem is solved ! Thank you very much ;)

@pingyangtiaer
Copy link

I changed the server_name to blog.mydomain.com in the re-named wordpress.cog file:
cat nginx/wordpress.conf
server {
listen 80;
server_name blog.mydomain.com;

root /var/www/html;
index index.php;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass wordpress:9000;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
}

}

However, when I tried to open the url: http://blog.mydomain.com it showed "The connection has timed out" which not working (however, if I changed blog.mydomain.com to 127.0.0.1 it works), would you please how can I make a subdomain instead a IP for the host name work?

@foch01 foch01 closed this as completed Jan 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants