Installed certbot, but now all site access over SSL is broken


#1

Hi, we’ve been running a server with multiple SSL-enabled sites on for a while, but have recently decided to switch over to Let’s Encrypt. I’ve followed the instructions from the server providers to get this working, but since installing the certbot software, all access to https:// links across the server fails, with a consistent error in the nginx log stating: no “ssl_certificate” is defined in server listening on SSL port while SSL handshaking.

Initally I installed certbot and hadn’t updated any of the certificates to Let’s Encrypt and we instantly noticed the failure, and having tried to user certbot to generate a Let’s Encrypt cert (which appears to have worked - the cert is on the server and is referenced in the domain conf file), found the same outcome with this.

Thanks for any guidance you can offer.

My domain is: https://www.preview.co.uk

I ran this command: installed certbot using instructions at https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-centos-7

It produced this output: “no “ssl_certificate” is defined in server listening on SSL port while SSL handshaking” (both when accessing newly installed Let’s Encrypt certs and pre-existing manually installed certs)

My web server is (include version): Linux

The operating system my web server runs on is (include version): CentOS7

My hosting provider, if applicable, is: Digital Ocean

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no


#3

can you post nginx config here


#4

yep no problem - just logging back in, will grab now


#5
user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
worker_connections  1024;
}


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

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

access_log  /var/log/nginx/access.log  main;

client_max_body_size  64M;

sendfile        on;
#tcp_nopush     on;

keepalive_timeout  65;

#gzip  on;

include /etc/nginx/conf.d/*.conf;

}


#6

please post the config file where Servername is defined.


#7

Cool, the following is for preview.co.uk, one of the sites on which I’ve tried to update the certificate to LE

server {
    listen   80;
    listen 443 ssl;

    ssl_certificate /etc/letsencrypt/live/preview.co.uk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/preview.co.uk/privkey.pem;
    ssl_protocols	TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    server_name preview.co.uk www.preview.co.uk;

    root   /var/www/preview.co.uk;
    index index.php index.html index.htm;

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

    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;

    location = /50x.html {
        root /usr/share/nginx/html;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

#8

Try removing the following directive:
listen 80;

in your configuration .

and add another block at the top

server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
}

and reload nginx


#9

ah, thanks - but no luck I’m afraid, have updated to the following. Now going to the non-https just offers a 404 error, and the https is showing the same error

server {
    listen 80;

    server_name preview.co.uk www.preview.co.uk;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;

    ssl_certificate /etc/letsencrypt/live/preview.co.uk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/preview.co.uk/privkey.pem;
    ssl_protocols    TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    server_name preview.co.uk www.preview.co.uk;

    root   /var/www/preview.co.uk;
    index index.php index.html index.htm;

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

    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;

    location = /50x.html {
        root /usr/share/nginx/html;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

#10

Have tried connecting to it over the command line with

openssl s_client -connect localhost:443 -servername preview.co.uk

which gave the following response:

CONNECTED(00000003)
139660236867488:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 316 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1514996967
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

#11

replace this with listen 443 default_server ssl;

restart nginx


#12

Fantastic! Thanks a million, that’s worked straight off. I’d tried adding default_server to the 443 line, but not when it was in a separate block of code. C’est la vie - thanks again!


#13

now http and https both are loading . If you need only ssl site , redirect all connections to https


#14

Thanks for the heads up, I’ll make sure to do that. Thanks for your help!


#15

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