Share

Question

Hi there! Trying to get nginx up and running for a pleroma instance. I was initially working off of this guide: https://docs.pleroma.social/debian_based_en.html#content. I’ve tried a bunch of things from around the internet to solve the problem of nginx just not wanting to be started, I’ll try to accurately enumerate them.

sudo service nginx start

returns

Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

systemctl status nginx

returns

 nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2019-07-18 19:46:13 UTC; 11min ago
     Docs: man:nginx(8)
  Process: 8665 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

nginx -t

returns

nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/sweetjams.club/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/sweetjams.club/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

the error.log file shows basically the same thing;

2019/07/18 20:07:57 [emerg] 8939#8939: BIO_new_file("/etc/letsencrypt/live/sweetjams.club/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/sweetjams.club/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

A common problem appears to be apache or something else using ports 80 or 440, I’ve already ensured that that is not the case here. It seems like I’ve got a .pem file missing, but tbh I don’t know what that is or where it should be or how to get one. So. Can anyone help me?

Answer 1

bobbyiliev MOD July 19, 2019

Hello,

Indeed the problem is that the .pem file is missing.

The .pem file is actually the SSL certificate for your sweetjams.club domain. You need to just add the SSL certificate in that /etc/letsencrypt/live/sweetjams.club/fullchain.pem file and the Nginx service should work as normal.

If you don’t have an SSL certificate for this domain name, you could install a Let’s Encrypt SSL instead:

https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04

Let me know if you need any help.

Regards,
Bobby

How To Secure Nginx with Let's Encrypt on Ubuntu 16.04

by Mitchell Anicas

In this tutorial, we will show you how to use Let's Encrypt to obtain a free SSL certificate and use it with Nginx on Ubuntu 16.04. We will also show you how to automatically renew your SSL certificate. If you're running a different web server, simply follow your web server's documentation to learn how to use the certificate with your setup.

isobel July 19, 2019

Thank you so much! Following the tutorial for Let’s Encrypt, sudo nginx -t fails with the error message

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/sweetjams.club/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/sweetjams.club/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

My nginx.conf currently looks like this

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

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

    ##
    # Gzip Settings
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}


#mail {
#   # See sample authentication script at:
#   # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#   # auth_http localhost/auth.php;
#   # pop3_capabilities "TOP" "USER";
#   # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#   server {
#       listen     localhost:110;
#       protocol   pop3;
#       proxy      on;
#   }
# 
#   server {
#       listen     localhost:143;
#       protocol   imap;
#       proxy      on;
#   }
#}

bobbyiliev MOD July 20, 2019

Hello,

In your /etc/nginx/sites-enabled/ folder there should be another config file, it should be called something like: your_domain_name.com.conf. What you could do is edit the file and remove the whole server block for port 443.

This should fix the error with the certificate, then you could follow the article and that way a new SSL will be issued and a new server block for port 443 will be added automatically.

NOTE: don’t forget to backup your file before making any changes.

Hope that this helps!
Bobby
- isobel July 20, 2019
  
  Hi Bobby!
  
  Thanks for the continued handholding, but there isn’t that file. In /etc/nginx/sites-enabled/ the only files are default and pleroma.nginx. What process generates that file?
  
  Artelis July 20, 2019
  
  You do. ;)
  
  It’s optional though, by default nginx uses that ‘default’ file, that’s actually the file where your site is currently configured, plus it looks like Pleroma has added another.
  
  That line near the end of the 'html’ block in 'nginx.conf’ pulls them in:
  
  include /etc/nginx/sites-enabled/*;
  
  Essentially they become part of “nginx.conf”, which is why it says the fault is in there:
  
  nginx: configuration file /etc/nginx/nginx.conf test failed
  
  … when it’s actually in one of those two. However, the issue is that it can’t find the certificate that should’ve been installed by certbot, and that’s the real mystery. What do you see in /etc/letsencrypt/live/sweetjams.club? Does it exist?
  
  isobel July 20, 2019
  
  Ah, I see about the config file :)
  
  But also, no, there’s no /live/ folder in /etc/letsencrypt/
  
  That seems wrong

Answer 2

isobel July 19, 2019

Thank you so much! Following the tutorial for Let’s Encrypt, sudo nginx -t fails with the error message

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/sweetjams.club/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/sweetjams.club/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

My nginx.conf currently looks like this

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

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

    ##
    # Gzip Settings
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}


#mail {
#   # See sample authentication script at:
#   # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#   # auth_http localhost/auth.php;
#   # pop3_capabilities "TOP" "USER";
#   # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#   server {
#       listen     localhost:110;
#       protocol   pop3;
#       proxy      on;
#   }
# 
#   server {
#       listen     localhost:143;
#       protocol   imap;
#       proxy      on;
#   }
#}

bobbyiliev MOD July 20, 2019

Hello,

In your /etc/nginx/sites-enabled/ folder there should be another config file, it should be called something like: your_domain_name.com.conf. What you could do is edit the file and remove the whole server block for port 443.

This should fix the error with the certificate, then you could follow the article and that way a new SSL will be issued and a new server block for port 443 will be added automatically.

NOTE: don’t forget to backup your file before making any changes.

Hope that this helps!
Bobby
- isobel July 20, 2019
  
  Hi Bobby!
  
  Thanks for the continued handholding, but there isn’t that file. In /etc/nginx/sites-enabled/ the only files are default and pleroma.nginx. What process generates that file?
  
  Artelis July 20, 2019
  
  You do. ;)
  
  It’s optional though, by default nginx uses that ‘default’ file, that’s actually the file where your site is currently configured, plus it looks like Pleroma has added another.
  
  That line near the end of the 'html’ block in 'nginx.conf’ pulls them in:
  
  include /etc/nginx/sites-enabled/*;
  
  Essentially they become part of “nginx.conf”, which is why it says the fault is in there:
  
  nginx: configuration file /etc/nginx/nginx.conf test failed
  
  … when it’s actually in one of those two. However, the issue is that it can’t find the certificate that should’ve been installed by certbot, and that’s the real mystery. What do you see in /etc/letsencrypt/live/sweetjams.club? Does it exist?
  
  isobel July 20, 2019
  
  Ah, I see about the config file :)
  
  But also, no, there’s no /live/ folder in /etc/letsencrypt/
  
  That seems wrong

Answer 3

isobel July 20, 2019

[deleted]

Artelis July 20, 2019

Replying here because it won’t let me reply above!

Yes, that’s very wrong… certbot should’ve put the certificates in there in step #4 of the tutorial posted above.

https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04#step-4-%E2%80%94-obtaining-an-ssl-certificate

What’s the result of:

sudo certbot certonly --dry-run -w /var/www/html -d sweetjams.club -d www.sweetjams.club

Note that this won’t actually create anything in /etc/letsencrypt/live because of the --dry-run. But if it works with no errors, run it again without the --dry-run part and hopefully that’ll be it fixed!

How To Secure Nginx with Let's Encrypt on Ubuntu 16.04

by Mitchell Anicas

In this tutorial, we will show you how to use Let's Encrypt to obtain a free SSL certificate and use it with Nginx on Ubuntu 16.04. We will also show you how to automatically renew your SSL certificate. If you're running a different web server, simply follow your web server's documentation to learn how to use the certificate with your setup.

isobel July 21, 2019

Running

sudo certbot certonly --dry-run -w /var/www/html -d sweetjams.club -d www.sweetjams.club

felt good, because it was a new thing to try! This is the result of that test.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running nginx -c /etc/nginx/nginx.conf -t.

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/sweetjams.club/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/sweetjams.club/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed


How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Nginx Web Server plugin - Alpha (nginx) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.sweetjams.club/.well-known/acme-challenge/U3v5cM3NhZ3mrAd5j6s9lF1usFfdhXa8nbbW_aSUzv4 [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame", sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://sweetjams.club/.well-known/acme-challenge/zTCI4wIHkUd6dAz07BhRJB8IiU8VkxRg4QK7mzTXO34 [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://www.sweetjams.club/.well-known/acme-challenge/U3v5cM3NhZ3mrAd5j6s9lF1usFfdhXa8nbbW_aSUzv4
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   Domain: sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://sweetjams.club/.well-known/acme-challenge/zTCI4wIHkUd6dAz07BhRJB8IiU8VkxRg4QK7mzTXO34
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

The log file in /var/log/letsencrypt is very long, and something I am able to parse even less than the rest of the things I have seen in the course of this project.

bobbyiliev MOD July 21, 2019

Hello,

Your domain name seems to be pointing to: 66.96.162.146. If this is not the IP address of your Drolet that you are running the cerbot command no, Let’s Encrypt would not be able to validate your domain name and certbot would fail.

Regards,
Bobby

Artelis July 21, 2019

Whoops! My mistake, I left --webroot off the command (option 3 in the menu it gave).

sudo certbot certonly --dry-run --webroot -w /var/www/html -d sweetjams.club -d www.sweetjams.club

Let’s Encrypt needs to verify that you’re the owner of the domain you’re requesting a certificate for, and that you have control over the server. To do that, certbot places a file in the webroot (by default /var/www/html, unless you’ve changed it - if so, change that in the command too.) The LE server then tries to access that file remotely, if it works then it gives you a certificate.

Right now, that’s the part that’s failing, it can’t access that file. So I’d try it with the --webroot option and see how that goes.

BUT, before that… we have a fun vicious circle going on - the LE server needs to access your site in order to send you a certificate… but nothing can access your site because it’s configured to use a certificate it doesn’t have yet! So we need to get the site up and running first, which means temporarily disabling some bits.

Open up that ‘default’ in /etc/nginx/sites-available and comment out anything starting with ssl, i.e.

ssl_certificate /etc/letsencrypt/live/sweetjams.club/fullchain.pem

Becomes:

# ssl_certificate /etc/letsencrypt/live/sweetjams.club/fullchain.pem

With all of those removed, nginx -t should finally be happy, and sudo service nginx restart should bring your site online. Then try the (corrected!) command I gave above.

If that works, run it again without the --dy-run to get your certificate. Then open up /etc/nginx/sites-available/default again and restore all those lines. Restart nginx again and that should be it!

Fingers crossed!

Edit: Oh, I forgot about the 'pleroma.nginx’ file - there may be ssl lines in there too. I can’t tell which of the two (or both) is configured to use SSL.

isobel July 21, 2019

So, there weren’t ssl records in ‘default’, but there were in 'pleroma.nginx’. I went ahead and commented them out, and the --dry-run --webroot command returned the following:

[sudo] password for dizzy:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://sweetjams.club/.well-known/acme-challenge/RtKG9iOMPcor109-qqQ-oyMSa66f4IkpFJtN8hmnlyg [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame", www.sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.sweetjams.club/.well-known/acme-challenge/f_W57gRA2RuRgVmL6H_7s2fBf-u3E0zozKLVQLcoGro [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://sweetjams.club/.well-known/acme-challenge/RtKG9iOMPcor109-qqQ-oyMSa66f4IkpFJtN8hmnlyg
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   Domain: www.sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://www.sweetjams.club/.well-known/acme-challenge/f_W57gRA2RuRgVmL6H_7s2fBf-u3E0zozKLVQLcoGro
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

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

nginx -t was up next, and gave me the following

nginx: [warn] conflicting server name "sweetjams.club" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "sweetjams.club" on [::]:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Hooray~ That seems like progress. sudo service nginx restart returned nothing, which I took to mean success. Running the –webroot command again got a little farther;

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.sweetjams.club/.well-known/acme-challenge/EHAhQgj5sm2-OeK0uaqZrPJVrQBe9OQqcXQxh0MDcPw [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame", sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://sweetjams.club/.well-known/acme-challenge/ocPX0YIJPcFGLNmC2TYscyypXuoBMCF7-XQb-aXCqXs [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://www.sweetjams.club/.well-known/acme-challenge/EHAhQgj5sm2-OeK0uaqZrPJVrQBe9OQqcXQxh0MDcPw
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   Domain: sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://sweetjams.club/.well-known/acme-challenge/ocPX0YIJPcFGLNmC2TYscyypXuoBMCF7-XQb-aXCqXs
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

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

Seems familiar. I checked out what @bobbyiliev said above about dns; in my domain control panel there were the dns records for 165.227.192.206, the ip address of my droplet, but also the default dns settings, for the 66.96.162.146 ip address. I deleted those records, now my control panel looks like this:

Control panel

Ping finds sweetjams.club as at the proper droplet ip address, but certbot still returns an error. It is at least a new error!

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: unknownHost :: No valid IP addresses found for www.sweetjams.club

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.sweetjams.club
   Type:   connection
   Detail: unknownHost :: No valid IP addresses found for
   www.sweetjams.club

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Artelis July 21, 2019

Curious. But progress!

Your site is actually being served, but that “#ad_frame” at the end of the response isn’t standard for a 404 error page, which makes me think it’s the pleroma.nginx file that’s handling everything - the fact that it’s the one with all the SSL stuff in it seems to agree.

It looks like that particular file is setting up a different webroot to the one that we’re telling certbot to use. If you open up /etc/nginx/sites-available/pleroma.nginx, look for a line that starts with root (in default you’ll see root /var/www/html;).

Try running the certbot command again, switching out the /var/www/html for whatever you see in pleroma.nginx.

Oh, and when you change an entry in the DNS, it takes a little time for any changes to propagate around the network. So when you tried the command the second time, whichever DNS Let’s Encrypt uses probably returned the old (now outdated) IP address for your droplet. It’ll fix itself soon enough!

Answer 4

Artelis July 20, 2019

Replying here because it won’t let me reply above!

Yes, that’s very wrong… certbot should’ve put the certificates in there in step #4 of the tutorial posted above.

https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04#step-4-%E2%80%94-obtaining-an-ssl-certificate

What’s the result of:

sudo certbot certonly --dry-run -w /var/www/html -d sweetjams.club -d www.sweetjams.club

Note that this won’t actually create anything in /etc/letsencrypt/live because of the --dry-run. But if it works with no errors, run it again without the --dry-run part and hopefully that’ll be it fixed!

How To Secure Nginx with Let's Encrypt on Ubuntu 16.04

by Mitchell Anicas

In this tutorial, we will show you how to use Let's Encrypt to obtain a free SSL certificate and use it with Nginx on Ubuntu 16.04. We will also show you how to automatically renew your SSL certificate. If you're running a different web server, simply follow your web server's documentation to learn how to use the certificate with your setup.

isobel July 21, 2019

Running

sudo certbot certonly --dry-run -w /var/www/html -d sweetjams.club -d www.sweetjams.club

felt good, because it was a new thing to try! This is the result of that test.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running nginx -c /etc/nginx/nginx.conf -t.

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/sweetjams.club/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/sweetjams.club/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed


How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Nginx Web Server plugin - Alpha (nginx) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.sweetjams.club/.well-known/acme-challenge/U3v5cM3NhZ3mrAd5j6s9lF1usFfdhXa8nbbW_aSUzv4 [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame", sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://sweetjams.club/.well-known/acme-challenge/zTCI4wIHkUd6dAz07BhRJB8IiU8VkxRg4QK7mzTXO34 [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://www.sweetjams.club/.well-known/acme-challenge/U3v5cM3NhZ3mrAd5j6s9lF1usFfdhXa8nbbW_aSUzv4
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   Domain: sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://sweetjams.club/.well-known/acme-challenge/zTCI4wIHkUd6dAz07BhRJB8IiU8VkxRg4QK7mzTXO34
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

The log file in /var/log/letsencrypt is very long, and something I am able to parse even less than the rest of the things I have seen in the course of this project.

bobbyiliev MOD July 21, 2019

Hello,

Your domain name seems to be pointing to: 66.96.162.146. If this is not the IP address of your Drolet that you are running the cerbot command no, Let’s Encrypt would not be able to validate your domain name and certbot would fail.

Regards,
Bobby

Artelis July 21, 2019

Whoops! My mistake, I left --webroot off the command (option 3 in the menu it gave).

sudo certbot certonly --dry-run --webroot -w /var/www/html -d sweetjams.club -d www.sweetjams.club

Let’s Encrypt needs to verify that you’re the owner of the domain you’re requesting a certificate for, and that you have control over the server. To do that, certbot places a file in the webroot (by default /var/www/html, unless you’ve changed it - if so, change that in the command too.) The LE server then tries to access that file remotely, if it works then it gives you a certificate.

Right now, that’s the part that’s failing, it can’t access that file. So I’d try it with the --webroot option and see how that goes.

BUT, before that… we have a fun vicious circle going on - the LE server needs to access your site in order to send you a certificate… but nothing can access your site because it’s configured to use a certificate it doesn’t have yet! So we need to get the site up and running first, which means temporarily disabling some bits.

Open up that ‘default’ in /etc/nginx/sites-available and comment out anything starting with ssl, i.e.

ssl_certificate /etc/letsencrypt/live/sweetjams.club/fullchain.pem

Becomes:

# ssl_certificate /etc/letsencrypt/live/sweetjams.club/fullchain.pem

With all of those removed, nginx -t should finally be happy, and sudo service nginx restart should bring your site online. Then try the (corrected!) command I gave above.

If that works, run it again without the --dy-run to get your certificate. Then open up /etc/nginx/sites-available/default again and restore all those lines. Restart nginx again and that should be it!

Fingers crossed!

Edit: Oh, I forgot about the 'pleroma.nginx’ file - there may be ssl lines in there too. I can’t tell which of the two (or both) is configured to use SSL.

isobel July 21, 2019

So, there weren’t ssl records in ‘default’, but there were in 'pleroma.nginx’. I went ahead and commented them out, and the --dry-run --webroot command returned the following:

[sudo] password for dizzy:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://sweetjams.club/.well-known/acme-challenge/RtKG9iOMPcor109-qqQ-oyMSa66f4IkpFJtN8hmnlyg [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame", www.sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.sweetjams.club/.well-known/acme-challenge/f_W57gRA2RuRgVmL6H_7s2fBf-u3E0zozKLVQLcoGro [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://sweetjams.club/.well-known/acme-challenge/RtKG9iOMPcor109-qqQ-oyMSa66f4IkpFJtN8hmnlyg
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   Domain: www.sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://www.sweetjams.club/.well-known/acme-challenge/f_W57gRA2RuRgVmL6H_7s2fBf-u3E0zozKLVQLcoGro
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

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

nginx -t was up next, and gave me the following

nginx: [warn] conflicting server name "sweetjams.club" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "sweetjams.club" on [::]:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Hooray~ That seems like progress. sudo service nginx restart returned nothing, which I took to mean success. Running the –webroot command again got a little farther;

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.sweetjams.club/.well-known/acme-challenge/EHAhQgj5sm2-OeK0uaqZrPJVrQBe9OQqcXQxh0MDcPw [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame", sweetjams.club (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://sweetjams.club/.well-known/acme-challenge/ocPX0YIJPcFGLNmC2TYscyypXuoBMCF7-XQb-aXCqXs [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n        <title>404 Error - Page Not Found</title>\r\n        <style>\r\n            #ad_frame"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://www.sweetjams.club/.well-known/acme-challenge/EHAhQgj5sm2-OeK0uaqZrPJVrQBe9OQqcXQxh0MDcPw
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

   Domain: sweetjams.club
   Type:   unauthorized
   Detail: Invalid response from
   http://sweetjams.club/.well-known/acme-challenge/ocPX0YIJPcFGLNmC2TYscyypXuoBMCF7-XQb-aXCqXs
   [66.96.162.146]: "<!DOCTYPE HTML>\r\n<html>\r\n\r\n    <head>\r\n
   <title>404 Error - Page Not Found</title>\r\n        <style>\r\n
   #ad_frame"

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

Seems familiar. I checked out what @bobbyiliev said above about dns; in my domain control panel there were the dns records for 165.227.192.206, the ip address of my droplet, but also the default dns settings, for the 66.96.162.146 ip address. I deleted those records, now my control panel looks like this:

Control panel

Ping finds sweetjams.club as at the proper droplet ip address, but certbot still returns an error. It is at least a new error!

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sweetjams.club
http-01 challenge for www.sweetjams.club
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: unknownHost :: No valid IP addresses found for www.sweetjams.club

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.sweetjams.club
   Type:   connection
   Detail: unknownHost :: No valid IP addresses found for
   www.sweetjams.club

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Artelis July 21, 2019

Curious. But progress!

Your site is actually being served, but that “#ad_frame” at the end of the response isn’t standard for a 404 error page, which makes me think it’s the pleroma.nginx file that’s handling everything - the fact that it’s the one with all the SSL stuff in it seems to agree.

It looks like that particular file is setting up a different webroot to the one that we’re telling certbot to use. If you open up /etc/nginx/sites-available/pleroma.nginx, look for a line that starts with root (in default you’ll see root /var/www/html;).

Try running the certbot command again, switching out the /var/www/html for whatever you see in pleroma.nginx.

Oh, and when you change an entry in the DNS, it takes a little time for any changes to propagate around the network. So when you tried the command the second time, whichever DNS Let’s Encrypt uses probably returned the old (now outdated) IP address for your droplet. It’ll fix itself soon enough!

Answer 5

isobel July 21, 2019

I guess there’s a limit on replies, it wouldn’t let me comment in that thread, but @Artelis, here we go!

The root lines in pleroma.nginx were commented out, I went ahead and uncommented them. The path was /var/lib/letsencrypt/. Running the –webroot command with that path gave the same error as above with Detail: unknownHost :: No valid IP address found for sweetjams.club.

Artelis July 21, 2019
I think (and stress “think”), that’s just the DNS propagation issue, because I’m able to ping your domain from my droplet and from my home with no issues. It seems to be taking a while, although it can take up to 24 hours for that change to work its way around the network.

I’ve also had a look at the pleroma.nginx that comes with Pleroma, and there’s actually a block in there specifically for what we’re trying to do.

This bit:

# Uncomment this if you need to use the 'webroot' method with certbot. Make sure # that the directory exists and that it is accessible by the webserver. If you followed # the guide, you already ran 'mkdir -p /var/lib/letsencrypt' to create the folder. # You may need to load this file with the ssl server block commented out, run certbot # to get the certificate, and then uncomment it. # # location ~ /\.well-known/acme-challenge { # root /var/lib/letsencrypt/; # }

When the DNS thing sorts itself out (hopefully soon!), uncomment this bit:

location ~ /\.well-known/acme-challenge { root /var/lib/letsencrypt/; }

… then restart nginx again and see if certbot is willing to play nice yet.

Edit: Wait, reading again I think that’s what you did! So now it’s just a waiting game for the DNS issues. I hope!
- isobel July 21, 2019
  
  That is what I did! I’ll give it a little time for DNS to propagate and check back in in the morning. Thanks so much for all your help so far!
  
  bobbyiliev MOD July 22, 2019
  
  I think that certbot and Let’s encrypt are quite ‘clever’ and check your DNS records directly in the nameservers that you use, which essentially means that you should give it about 5-10 minutes and certbot should be able to pickup the correct A record.
  
  Let us know how it goes!
  Bobby
  
  isobel July 22, 2019
  
  I’m still getting the following error:
  
  Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for www.sweetjams.club Using the webroot path /var/lib/letsencrypt for all unmatched domains. Waiting for verification... Cleaning up challenges Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: unknownHost :: No valid IP addresses found for www.sweetjams.club IMPORTANT NOTES: - The following errors were reported by the server: Domain: www.sweetjams.club Type: connection Detail: unknownHost :: No valid IP addresses found for www.sweetjams.club To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.
  
  Should my DNS records look different than this?
  
  bobbyiliev MOD July 22, 2019
  
  The error is saying that your www version can not be verified. You need to edit your DNS zone and add a CNAME record for your www version to point to your domain. This would fix the error that you are getting.
  
  Regards,
  Bobby
  
  Artelis July 22, 2019
  
  Gah! Still progress, it was complaining about both domains before, now we’re down to just one. It can find “sweetjams.club” but has no idea where “www.sweetjams.club” is… you and I know it’s the same server, but the technology needs help.
  
  @bobbyiliev is correct, you need to add a CNAME record (hostname “www”, is an alias of “@”). And uh, hopefully not wait too long for that change to propagate.
  
  On that note, have a look in pleroma.nginx again and check the server_name line - make sure it has both versions of your domain in there:
  
  server_name sweetjams.club www.sweetjams.club;

Answer 6

Artelis July 21, 2019
I think (and stress “think”), that’s just the DNS propagation issue, because I’m able to ping your domain from my droplet and from my home with no issues. It seems to be taking a while, although it can take up to 24 hours for that change to work its way around the network.

I’ve also had a look at the pleroma.nginx that comes with Pleroma, and there’s actually a block in there specifically for what we’re trying to do.

This bit:

# Uncomment this if you need to use the 'webroot' method with certbot. Make sure # that the directory exists and that it is accessible by the webserver. If you followed # the guide, you already ran 'mkdir -p /var/lib/letsencrypt' to create the folder. # You may need to load this file with the ssl server block commented out, run certbot # to get the certificate, and then uncomment it. # # location ~ /\.well-known/acme-challenge { # root /var/lib/letsencrypt/; # }

When the DNS thing sorts itself out (hopefully soon!), uncomment this bit:

location ~ /\.well-known/acme-challenge { root /var/lib/letsencrypt/; }

… then restart nginx again and see if certbot is willing to play nice yet.

Edit: Wait, reading again I think that’s what you did! So now it’s just a waiting game for the DNS issues. I hope!
- isobel July 21, 2019
  
  That is what I did! I’ll give it a little time for DNS to propagate and check back in in the morning. Thanks so much for all your help so far!
  
  bobbyiliev MOD July 22, 2019
  
  I think that certbot and Let’s encrypt are quite ‘clever’ and check your DNS records directly in the nameservers that you use, which essentially means that you should give it about 5-10 minutes and certbot should be able to pickup the correct A record.
  
  Let us know how it goes!
  Bobby
  
  isobel July 22, 2019
  
  I’m still getting the following error:
  
  Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for www.sweetjams.club Using the webroot path /var/lib/letsencrypt for all unmatched domains. Waiting for verification... Cleaning up challenges Failed authorization procedure. www.sweetjams.club (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: unknownHost :: No valid IP addresses found for www.sweetjams.club IMPORTANT NOTES: - The following errors were reported by the server: Domain: www.sweetjams.club Type: connection Detail: unknownHost :: No valid IP addresses found for www.sweetjams.club To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.
  
  Should my DNS records look different than this?
  
  bobbyiliev MOD July 22, 2019
  
  The error is saying that your www version can not be verified. You need to edit your DNS zone and add a CNAME record for your www version to point to your domain. This would fix the error that you are getting.
  
  Regards,
  Bobby
  
  Artelis July 22, 2019
  
  Gah! Still progress, it was complaining about both domains before, now we’re down to just one. It can find “sweetjams.club” but has no idea where “www.sweetjams.club” is… you and I know it’s the same server, but the technology needs help.
  
  @bobbyiliev is correct, you need to add a CNAME record (hostname “www”, is an alias of “@”). And uh, hopefully not wait too long for that change to propagate.
  
  On that note, have a look in pleroma.nginx again and check the server_name line - make sure it has both versions of your domain in there:
  
  server_name sweetjams.club www.sweetjams.club;

Answer 7

isobel July 22, 2019

Hit the reply cap again! @bobbyiliev my DNS table now looks like this Does that look right to you? I’m still getting the No valid IP address error.

bobbyiliev MOD July 22, 2019

Hey,

You need to change it a bit:

The record is ok
The Name should be just: www
And the content should be: sweetjams.club

Then this should work!

Regards,
[Bobby](http://)
- isobel July 22, 2019
  
  It seems to all be working! The dryrun passed, I got the .pem files, and a whole bunch of other stuff happened! Now I’ve got an A rank at SSLlabs.com. Thank you both so much for your help! Now I just have to figure out all the other wiggly stuff going on with my as-yet hypothetical pleroma instance.
  
  Artelis July 22, 2019
  
  Great! Have fun figuring out the wigglies. ;)
  
  bobbyiliev MOD July 22, 2019
  
  Great! Happy to hear that it’s a working Now!
  
  Regards,
  Bobby

Answer 8

bobbyiliev MOD July 22, 2019

Hey,

You need to change it a bit:

The record is ok
The Name should be just: www
And the content should be: sweetjams.club

Then this should work!

Regards,
[Bobby](http://)
- isobel July 22, 2019
  
  It seems to all be working! The dryrun passed, I got the .pem files, and a whole bunch of other stuff happened! Now I’ve got an A rank at SSLlabs.com. Thank you both so much for your help! Now I just have to figure out all the other wiggly stuff going on with my as-yet hypothetical pleroma instance.
  
  Artelis July 22, 2019
  
  Great! Have fun figuring out the wigglies. ;)
  
  bobbyiliev MOD July 22, 2019
  
  Great! Happy to hear that it’s a working Now!
  
  Regards,
  Bobby

Answer 9

odoomydata November 14, 2019

Hello below is my nginx.conf file : PLEAE CHECK ALL IS OK.IF WRONG PLEASE CORRECT ME. MY WEBPAGE IS NOT SHOWING WHAT I WANT. I INSTALLED ODOO 12 AND LINK ODOO WITH DOMAIN BUT WHEN I ENTER surveyspan.com odoo will work but when i enter https://www.surveyspan.com it will showing Welcome to nginx.
Please help me for this.

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
workerconnections 768;
# multiaccept on;
}

http {
##
# Basic Settings
##
sendfile on;
tcpnopush on;
tcpnodelay on;
keepalivetimeout 65;
typeshashmaxsize 2048;
# server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##
    server  {

            listen 443;
            server_name surveyspan.com;
            ssl on;
            ssl_certificate /etc/ssl/certs/surveyspan_com.crt;
            ssl_certificate_key /etc/ssl/private/surveyspan.key;
            ssl_prefer_server_ciphers on;
    }
            ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
            ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

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

    # Gzip Settings
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/odoosurvey.com*;

}

nginx.service failure

Leave a Comment

Share

Share your Question

nginx.service failure

Leave a Comment

Related

question

What is the virtual host configuration for a ZF3 application with nginx?

question

It has been 3 days and my domain is still not active

question

After applying cloud firewall my site is not working!!

question

WHat does 'thr'mean in htop

Almost there!