Nginx erreur EMERG [Résolu]


#1

Bonjour

Le problème que je vais exposer n’est pas spécifique à Debian. Du fait du SE que j’utilise, OpenBSD, je mets donc ce poste dans “Pause Café”. Si certains peuvent m’aider, soit à trouver la solution, soit à me diriger vers des personnes encore plus qualifiées, tant mieux…

J’ai le message d’erreur suivant :

# nginx -t                                      
nginx: [emerg] BIO_new_file("/etc/nginx/$file_fullchain") failed (SSL: error:02FFF002:system library:func(4095):No such file or directory:fopen('/etc/nginx/$file_fullchain', 'r') error:20FFF080:BIO routines:CRYPTO_internal:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

En fait, nginx est en v 1.14.2 - depuis la 1.13, il est possible d’utiliser TLS v1.3.
Malheureusement, je n’ai pas fait attention que LibreSSEL ne le supportait pas encore. Seul OpenSSL v1.1.1* le peut !

Bref, donc, je modifies un seul fichier sur un seul domaine que je gère… je rajoute TLS v1.3 à TLS v1.2, ainsi que les chiffrements TLS adéquats.
Et, au moment de tester la configuration de nginx, j’ai donc le message d’erreur ci-dessus.

Je supprime cette modification de configuration, en mettant la sauvegarde de mon ancienne configuration fonctionnelle, elle juste avec TLS v1.2, et malgré tout, non seulement , j’ai toujours cette erreur fatidique, mais le service ne peut pas redémarrer !
Résultat, tous les domaines web, sur ce server sont down… (bonjour, le stress grave) :frowning:

J’ai bien essayé de supprimer nginx et les différents paquets liés, pour les réinstaller… rien à faire, même résultat d’échec !

Je ne sais vraiment pas quoi faire !?

Une idée ?


#2

Bonjour,

En partant du principe que le message d’erreur est explicite :

peut-on voir le fichier de configuration que tu as modifié, pour comprendre pourquoi une directive appelle un fichier avec $file_fullchain ?
Cela suggère une directive ssl_certificate erronée ou un oubli de « ; » en fin de directive…

Le retour de :
nginx -t
peut aider.


#3

Le retour de nginx -t est publié ci-dessus :wink:
(tel quel… aussi surprenant que cela paraisse ; c’est textuellement cela)

J’ai juste modifié :

ssl_protocols TLSv1.2;
ssl_ciphers
'EECDH+CHACHA20:EECDH+AESGCM:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;

En:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers
'TLS13+AESGCM+AES128:EECDH+CHACHA20:EECDH+AESGCM:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

Ni plus ni moins !
Puis exécuté l’option ‘-t’ pour tester…


#4

Aïe, j’ai pas les yeux en face des trous :wink: Désolé.
Peux-tu montrer l’ensemble du fichier ?


#5

Ça va être compliqué parce que c’est un ensemble de fichiers atomiques appelés par le fichier principal :

Le fichier principal - lui anonymisé :

#template: HTTPS

#include /etc/nginx/cfg/mydomain.net/upstream.cfg;
#include /etc/nginx/cfg/mydomain.net/301_from_www.cfg;
#include /etc/nginx/cfg/mydomain.net/301_to_www.cfg;
include /etc/nginx/cfg/mydomain.net/301_to_https.cfg;

server {
    include /etc/nginx/cfg/mydomain.net/port_https.cfg;

    ###########
    ### SSL cfguration
    ###########
    include /etc/nginx/cfg/mydomain.net/ssl.cfg;

    server_name mydomain.net www.mydomain.net;

    if ($host = 'www.mydomain.net') {
        rewrite  ^/(.*)$  https://mydomain.net/$1  permanent;
    }

    root /var/www/htdocs/mydomain.net/www/;

    access_log  /var/www/logs/mydomain.net/access.log compression if=$loggable buffer=256k flush=5m;
    access_log  /var/www/logs/mydomain.net/mydomain.net.access.log compression if=$loggable;
    error_log   /var/www/logs/mydomain.net/errors.log;

    include /etc/nginx/cfg/mydomain.net/headers_ssl.cfg;
    include /etc/nginx/cfg/mydomain.net/headers.cfg;

    ##########
    ### Limit connections
    ##########
    include /etc/nginx/cfg/mydomain.net/limit.cfg;

    ##########
    ### Block Bots
    #########
    include /etc/nginx/bots.d/blockbots.conf;
    include /etc/nginx/bots.d/ddos.conf;

    ##########
    ### Manage returns errors
    ##########
    #include /etc/nginx/cfg/mydomain.net/return_403.cfg;
    include /etc/nginx/cfg/mydomain.net/return_444.cfg;

    ##########
    ### rewritings!
    ##########
    include /etc/nginx/cfg/mydomain.net/rewrite.cfg;
    #rewrite ^/.well-known/carddav /cal/$remote_user/carddav/ redirect;
    #rewrite ^/.well-known/caldav /cal/$remote_user/caldav/ redirect;

    ##########
    ### locations
    ##########

    location / {

	index index.php index.html;

        include /etc/nginx/cfg/mydomain.net/deny_reserved_ip.cfg;

	#if ($request_method !~ ^(GET|HEAD|POST)$) { return 444; }

        #satisfy any;
        #allow 192.168.47.0/24;
        #deny all;
        #auth_basic "Acces Restreint";
        #auth_basic_user_file $dir_htaccess/$file_htpasswd;

        #rewrite ^/.well-known/carddav /cal/$remote_user/carddav/ redirect;
        #rewrite ^/.well-known/caldav /cal/$remote_user/caldav/ redirect;

        try_files $uri $uri/ =404;

    }

    location /img/ {
	autoindex on;
    }
    location /share/ {
	autoindex on;
    }

    location /share/BlockZones/lists/README {
        default_type "text/plain";
    }

    # mng well_known config
    include /etc/nginx/cfg/mydomain.net/well_known.cfg;

    # mng cal
    #include /etc/nginx/cfg/mydomain.net/radicale.cfg;

    # BlackHole config
    include /etc/nginx/cfg/mydomain.net/blackhole.cfg;

    # pass the PHP scripts to FastCGI server...
    include /etc/nginx/cfg/mydomain.net/php.cfg;

    # manage errors
    include /etc/nginx/cfg/mydomain.net/mng_errors.cfg;

    # see FPM status
    #include /etc/nginx/cfg/mydomain.net/fpm_status.cfg;

    # deny access to .htaccess files
    #include /etc/nginx/cfg/mydomain.net/htaccess.cfg;

    # manage favicon
    include /etc/nginx/cfg/mydomain.net/favicon.cfg;

    # manage images
    include /etc/nginx/cfg/mydomain.net/img.cfg;

    # manage robots.txt
    include /etc/nginx/cfg/mydomain.net/robots.cfg;

    # manage scripts CSS/JS
    include /etc/nginx/cfg/mydomain.net/scripts.cfg;

    # manage hidden files
    #include /etc/nginx/cfg/mydomain.net/hidden.cfg;

}

Le fichier port_https.cfg:

listen 443 ssl http2;
listen [::]:443 ssl http2;

#spdy_headers_comp 9;
ssl on;

Le fichier ssl.cfg:

ssl_buffer_size 4k; # 16k, for throughput, video applications

ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
#ssl_session_ticket_key 	/etc/nginx/cfg/mydomain.net/t.k; 
ssl_session_timeout 1h;

ssl_certificate 	/etc/ssl/acme/mydomain.net.fullchain.pem;
ssl_certificate_key	/etc/ssl/acme/private/mydomain.net.privkey.pem;
ssl_dhparam 		/etc/nginx/cfg/mydomain.net/dhp_4096.pem;

ssl_ecdh_curve X25519:P-521:P-384;

# Mozilla Modern Config
ssl_protocols TLSv1.2;
ssl_ciphers 'EECDH+CHACHA20:EECDH+AESGCM:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/acme/mydomain.net.chain.pem;

resolver 80.67.169.12 80.67.169.40 [2001:910:800::12] [2001:910:800::40] valid=300s;
resolver_timeout 3s;

Voilà, c’est ce fichier que j’avais modifié !
(ni + ni -)


#6

Je ne vois pas d’erreur mais tu devrais essayer de rechercher ce qui provoque l’erreur dans le dossier contenant tous les fichiers de config :

rgrep  "/etc/nginx/$file_fullchain" /etc/nginx

#7

rgrep n’existe pas sous OpenBSD.
mais un grep -r devrait faire l’affaire :wink:

Par contre, ça me ressort 800 lignes traitées !!!


#8

Il y aurait 800 lignes avec le motif recherché ? Ce n’est pas possible.
Peux-tu essayer avec cette syntaxe :

grep -R  'file_fullchain' /etc/nginx/*

Il y a plusieurs choses étonnantes et illogiques dans ton problème :

  • l’erreur indique un nom de fichier avec quelque chose qui ressemble à une variable non substituée : $file_fullchain ;
  • l’erreur est toujours la même après avoir remis le fichier dans son état d’origine. J’en déduis que tu as modifié autre chose, ou que tu n’as pas modifié le bon fichier, ou que tu as modifié les droits d’accès sur certains fichiers.

Cette erreur concerne bien SSL et un fichier appelé par un directive ssl qui n’est pas accessible. Si tu es sûr de n’avoir modifié que le fichier ssl.cfg et uniquement celui-ci, vérifie les droits sur ce fichier et sur tous les fichiers qu’il appelle via des directives ssl_***


#9

Bonjour,
J’ai eu d’autres soucis qui m’ont capturé autrement.
Pour info, je suis entrain de migrer les sites web que je gère vers le serveur web natif httpd.
D’autant que le SE du serveur a été upgradé vers 6.6, et que la version de Nginx a été mise à jour aussi, maintenant c’est la 1.16.1.

Mais juste pour le propos, le sujet étant lancé ; aussi bizarre que cela paraisse.

  • Non je n’ai strictement en rien modifié le message d’erreur que retourne nginx, il est restitué tel quel !!! (Et, j’en suis le premier surpris, mais c’est la réalité)
  • Oui, je n’ai modifié QUE ce fichier ssl.cfg et pour le restaurer, suis allé cherché une sauvegarde de l’état antérieur, qui lui fonctionnait !
  • Non, je n’ai modifié aucun autre fichier… vraiment aucun ! J’ai vraiment juste modifié le fichier ssl.cfg, tel que décrit, et ait simplement voulu redémarré nginx, mais le test de la configuration le met en erreur.
  • Oui, les droits sont bons : -rw-r--r-- 1 root wheel 1711 Oct 26 15:33 ssl.cfg

Concernant le retour du grep demandé :

grep -R  'file_fullchain' /etc/nginx/*
/etc/nginx/cfg/cld.stephane-huc.net/ssl.cfg.sav:ssl_certificate $file_fullchain;
/etc/nginx/cfg/en.stephane-huc.net/ssl.cfg.sav:ssl_certificate $file_fullchain;
/etc/nginx/cfg/huc.fr.eu.org/ssl.cfg:ssl_certificate $file_fullchain;
/etc/nginx/cfg/huc.fr.eu.org/ssl.cfg.sav:ssl_certificate $file_fullchain;

Je viens de comprendre : c’est le site “huc.fr.eu.org” - que j’avais précédemment activé, mais pour lequel je n’avais pas pu avoir de certificat SSL à cause du client acme, défectueux !
Et, après l’avoir désactivé, en effet nginx redevient normal !!!

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

@Bruno1: Un grand merci, sur ce coup-là… tu m’as bien aidé à discerner mon pb.
Ayant des soucis de mémoire, j’avais complètement oublié que j’avais cherchais à activer ce domaine quelques jours auparavant !!!