Problème de clés de certification

Bonjour,
J’ai eu un soucis après avoir dépassé le délai de validité de clés authentifiés par startSSL. j’avais des clés et des dossiers un peu partout. J’ai déplacé les anciennes clés dans d’autres fichiers et essayé de retrouver les premières clés, mais je n’avait pas du bien faire la sauvegarde, ou pas clairement. J’ai régénéré des clé avec le tutto de Yunohost, maintenant j’arrive à me reconnecter sur le serveur en passant par chromium, mais quand je passe par firefox (iceweasel our moi), ça bloque quand je suis chez moi, (pas de l’extérieur). Plus bizarre, quand j’ouvre ma boîte aux lettres Thunderbird (icedove pour moi) de chez moi qui est indépendante du serveur (même si une des adresses mail avait été utilisée pour la clé startssl), j’ai un avertissement comme quoi le site essaye de s’identifier avec lui-même. Donc je pense qu’il y a quelquechose qui ne va pas dans cette config…

voici des logs que retrouve :

# sudo tail /var/log/nginx/*error.log
==> /var/log/nginx/error.log <==
2015/11/08 12:41:51 [alert] 2734#0: aborting
2015/11/08 12:43:56 [info] 5232#0: Using 32768KiB of shared memory for push module in /etc/nginx/nginx.conf:63
2015/11/08 12:43:56 [info] 5232#0: [lua] init.lua:52: SSOwat ready
2015/11/08 14:20:49 [info] 5820#0: Using 32768KiB of shared memory for push module in /etc/nginx/nginx.conf:63
2015/11/08 14:20:49 [info] 5820#0: [lua] init.lua:52: SSOwat ready
2015/11/08 14:20:54 [alert] 5243#0: *298 open socket #24 left in connection 6
2015/11/08 14:20:54 [alert] 5243#0: *299 open socket #34 left in connection 7
2015/11/08 14:20:54 [alert] 5243#0: aborting
2015/11/08 16:24:41 [info] 6106#0: Using 32768KiB of shared memory for push module in /etc/nginx/nginx.conf:63
2015/11/08 16:24:41 [info] 6106#0: [lua] init.lua:52: SSOwat ready

==> /var/log/nginx/jirafeau.rodinux.fr-error.log <==

==> /var/log/nginx/rodinux.fr-error.log <==
2015/11/08 14:14:40 [error] 5243#0: *311 FastCGI sent in stderr: "PHP message: PHP Warning:  file_put_contents(tmp/page.af3906cfde643ae7f290cfdc51cc9342.rtpl.php): failed to open stream: Permission denied in /var/www/zerobin/lib/rain.tpl.class.php on line 324" while reading response header from upstream, client: 192.168.0.10, server: rodinux.fr, request: "GET /zerobin/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "rodinux.fr", referrer: "https://rodinux.fr/jappix/"

==> /var/log/nginx/www.rodinux.fr-error.log <==
2015/11/08 12:57:12 [error] 5239#0: *42 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 157.55.39.255, server: www.rodinux.fr, request: "GET /wiki/wiki.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "www.rodinux.fr" 

qu’est qui a bien pu se passer ?

Je ne comprends pas, après avoir de nouveau régénérer les clés, j’ai toujours, ce message d’erreur.
J’ai un doute, mon problème est survenu quand mes certificats StartSSL expiraient. J’avais commencer à me réinscrire sur le site de StartSSL qui me donnait des clés provisoire qui dure un mois je crois et qu’il faut renouveler ensuite pour qu"elle soit valable un an. ça c’était le 23/10/2015, mais je ne me suis pas occuper de l’installer sur le serveur… Par contre, je ne me rappelle pas si pour cette nouvelle clé j’ai juste donner mon mail (qui n’est pas un mail configurer sur le serveur), ou si j’ai du donner aussi le nom du serveur (mais je ne crois pas). Du coup une question me taraude, si à tout hasard, j’avais sans m’en rappeler donner le nom de mon serveur à StartSSl, est-ce que ce ne serait pas la raison pour laquelle j’ai des erreurs localement avec mes clé régénérées, qui du coup seraient en conflit avec la prise en compte provisoire des clés de Startssl ? à priori si je ne renouvelle pas tout de suite, la clé expire un mois après la demande, donc vers le 23/11/2015 ?

Si le problème persiste, Je crois que je vais tenter une réinstallation, j’ai sauvegardé les bases de données avec cette commande

 mysqldump -uroot"$(sudo cat /etc/yunohost/mysql)" --single-transaction --default-character-set=utf8 --events --ignore-table=mysql.event --all-databases > /tmp/all_databases_backup.sql

en espérant que c’est bien ce qu’il fallait faire… puis j’ai sauvegardé les fichiers /etc ; /home ; /var/www ; /usr/share/yunohost. Mais si ce que je décrit au-dessus est véridique, je risque d’avoir les mêmes soucis…

Je pense que tu devrais tout simplement faire oublier les certificats de ton domaine à iceweasel (préférence/avancé/certificats), puis tu devras de nouveau faire une exception de sécurité la prochaine fois que tu te connecteras à ton serveur.

j’ai déjà fait, mais ça ne fonctionne pas. Autre comportement étrange, sur un autre pc, avec iceweasel aussi mais pas de boîte mail configurée, il ma propose d’ajouter le certificat du serveur m_n_d.tld, mais après si j’essaie d’aller sur le site www.m_n_d.tld, il refuse et l’inverse aussi, il faut à chaque fois que je supprime le certificat pour accepter…C’est vraiment bizarre

si tu as un domaine m_n_d.tld et www.m_n_d.tld . www.m_n_d.tld, c’est un autre domaine donc c’est normal que ce soit un autre certificat.
Ça veut dire quoi “et l’inverse aussi” ?

ben si je me connecte au sso, j’y accède (que avec chromium), si j’essaie d’ouvrir le sous-domaine en même temps (www) impossible, ou l’inverse, je vais sur le sous domaine (www) et j’accède pas au sso… J’ai vraiment un truc qui cloche…

parmi tes certificats il n’y aurait pas des wildcards, par hasard ?

si tu as un wildcard pour m_n_d.tld ça expliquerait que ça chie avec www.m_n_d.tld

ben non, pas avec ce sous domaine, j’ai un autre hébergement chez ovh avec un * mais pas celui-ci…

Tu as bien créé le domaine www.rodinux.fr sur yunohost en plus de ton domaine principal rodinux.fr ?
Ou sinon (plus probable) tu as copié le même certificats pour les deux domaines, il faut que tu en recrée un pour www.rodinux.fr afin qu’il ait un numéro de série différent du premier : rodinux.fr

ok, en effet c’est les mêmes certificats sur les nom de domaine et le sous domaine… comment je m’y prends pour refaire un certificat ? Est-ce que j’ai pas intérêt dans refaire un sur chacun d’eux vu qu’il me semble que ceux qui sont présent sont régénérer à partir de certificats qui venaient de StartSSL ??

Bon, avec de l’aide précieuse, j’ai pu réparer les clés. Il aura fallu régénérer celle du domaine www.m_n_d.tld où se trouvait un site Wordpress. Pour cela je donne l’astuce si jamais elle sert… J’ai changer le nom du domeine du site provisoirement dans un fichier .yml (il faut que je me rappelle lequel pour terminer cette explication) afin de ne pas perdre le Wordpress, pour ensuite supprimer le domaine en question, puis le réinstaller, ce qui lui a permis de régénérer la bonne clé…
Puis pour de nouveau accéder au wordpress ces commandes :

sudo touch /etc/nginx/conf.d/www.rodinux.fr.d/wordpress.conf

on créer ce fichier, puis on l’édite

sudo nano  /etc/nginx/conf.d/www.rodinux.fr.d/wordpress.conf

et on ajoute ceci :

location / {
       alias /var/www/wordpress/;
       index index.php;
       if (!-e $request_filename)
       {
        rewrite ^(.+)$ /index.php?q=$1 last;
       }
       client_max_body_size 30m;
       location ~ [^/]\.php(/|$) {
           fastcgi_split_path_info ^(.+?\.php)(/.*)$;
           fastcgi_pass unix:/var/run/php5-fpm.sock;
           fastcgi_index index.php;
           include fastcgi_params;
           fastcgi_param REMOTE_USER     $remote_user;
           fastcgi_param PATH_INFO       $fastcgi_path_info;
           fastcgi_param SCRIPT_FILENAME $request_filename;
       }
}

puis on recharge nginx

sudo service nginx reload

Voilà. bon, j’ai toujours un soucis avec mon navigateur Firefox sur un de mes pc qui ne veut pas ouvrir le serveur, il faut que je supprime des certificats dans les avancées, j’attends qu’il finisse pas accepter de me donner la possibilité de prendre le certificat du serveur…

Pour le message d’erreur dans la boîte aux lettres, cela venait des calendriers Caldav synchronisés acec une extension calendrier de thunderbird. pour l’instant je ne peux l’activer tant qu j’ai ce soucis d’acceptation de certificats avec Firefox…

Je viens de trouver une solution, c’était d’utiliser l’outil de restauration de Firefox, cool, j’ai pu accepter la clé :slight_smile:

Salut @rodinux !
Je crois que j’ai un souci assez proche du tien:

Suite à bug que je n’arrivais pas à régler, j’ai refait l’installation de mon site. Depuis, j’ai le message “Connexion non-certifiée” de Iceweasel, sans pouvoir ajouter une exception de sécurité.
J’ai espéré qu’obtenir un certificat d’un autorité officiel grâce à Let’s Encrypt permettrait de contourner le problème, mais j’ai eu ce message d’erreur:

Failed authorization procedure. mon_domaine.tld (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Error parsing key authorization file: Invalid key authorization: 19 parts

IMPORTANT NOTES:

  • If you lose your account credentials, you can recover through
    e-mails sent to admin@mon_domaine.tld.
  • The following errors were reported by the server:

Domain: mon_domaine.tld
Type: urn:acme:error:unauthorized
Detail: Error parsing key authorization file: Invalid key
authorization: 19 parts

Visiblement ce problème de certificat invalide bloque aussi le serveur de vérification de Let’s Encrypt…

Aurais-tu une idée de comment je pourrais générer de nouvelles clés de certification, ou utiliser celles de ma premières installation (j’ai utilisé une nouvelle carte µSD).

Merci!

Je pense que tu n’as pas lancé le script en tant que super-utilisateur. Réessaye de le lancer en root

Oups, j’aurais dû revenir, j’ai finalement résolu ce problème

Mais je n’ai pas bien compris laquelle des manips à été efficace:

  • j’ai refait un certificat via l’interface d’administration:
    Outils > Télécharger l’autorité de certification SSL (CA)

  • j’ai lancé le script en ajoutant -W à la fin pour ignorer le message d’erreur

~/letsencrypt# ./letsencrypt-auto --help -W ignore

Merci!